TypeScript type declarations shipped
Why it matters
Shipping an npm package without TypeScript declarations means every consumer is flying blind. IDEs show any for all imports, type errors go unreported until runtime, and documentation-on-hover disappears entirely. ISO 25010 analysability collapses — developers must clone your repo just to understand your API surface. For TypeScript projects (now the majority of serious npm consumers), a package without .d.ts files is effectively unusable without manual declare module workarounds.
Severity rationale
Critical because the absence of type declarations renders the package untyped for all TypeScript consumers, eliminating IDE autocompletion, type checking, and compile-time safety.
Remediation
Enable declaration generation in tsconfig.json, configure your build tool to emit .d.ts files, and reference them in package.json.
// tsconfig.json
{
"compilerOptions": {
"declaration": true,
"declarationMap": true,
"outDir": "dist"
}
}
// tsup.config.ts
import { defineConfig } from 'tsup'
export default defineConfig({ entry: ['src/index.ts'], format: ['esm', 'cjs'], dts: true })
// package.json
{
"types": "./dist/index.d.ts",
"exports": { ".": { "types": "./dist/index.d.ts" } }
}
Verify declarations exist after build: ls dist/*.d.ts. Declarations auto-typed as any do not satisfy this check.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the SDK / Package Quality Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.analysability — Analysability — type information aids consumer debugging
- iso-25010:2011 · compatibility.interoperability — Interoperability — TypeScript toolchain integration
Taxons
History
- 2026-04-18·v1.0.0·Initial import from sdk-package-quality·automated