Fix TS7016: Could Not Find Declaration File for Module

You import a perfectly normal npm package and TypeScript stops you:

Could not find a declaration file for module 'some-lib'.
'.../node_modules/some-lib/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/some-lib` if it exists or add a new
  declaration (.d.ts) file containing `declare module 'some-lib';`

This is TS7016. TypeScript even prints its own two suggested fixes. This guide explains when each is right, plus the case the message doesn't mention: the package may already ship types.

Why it happens#

TS7016 fires when all three are true:

1. You import a module that resolves to a plain JavaScript file with no bundled .d.ts, and
2. there is no @types/X package installed, and
3. noImplicitAny is on (it is, under strict).

Without type information the module would silently become any. The noImplicitAny docs put it plainly: with the flag on, "TypeScript will issue an error whenever it would have inferred any." So TS7016 is the protection working — not a broken install.

Fix 1 (preferred) — Install the DefinitelyTyped types#

npm install --save-dev @types/some-lib

How to know it exists: DefinitelyTyped publishes type packages to npm under the @types scope with the same name as the underlying package (react → @types/react). Per the handbook, "TypeScript automatically finds type definitions under node_modules/@types, so there's no other step needed." If the install errors with 404, no community types exist — go to Fix 3.

Fix 2 — Check if the package already ships types#

Sometimes TS7016 is misdiagnosed: the package does bundle types and you're chasing a phantom. Look in the dependency's package.json for a types (or its synonym typings) field:

{
  "main": "./lib/main.js",
  "types": "./lib/main.d.ts"
}

If a package bundles types but you still see TS7016, suspect a stale install, a typesVersions mismatch for your TS version, or an exports map that doesn't expose the .d.ts under your moduleResolution. The fix there is reinstalling or adjusting module resolution — not adding @types.

A related variant: the mismatch appears right after bumping TypeScript itself — npm install typescript@latest breaks the build with Cannot find module '@types/node' or Property 'auth' does not exist on SupabaseClient. That's not a missing-types issue but a module/moduleResolution drift between the compiler and @types/node; the dedicated guide to aligning TypeScript and @types/node covers realigning both in one pass.

Fix 3 — Write a local declaration#

When neither @types/X nor bundled types exist, declare the module yourself. Create a file like src/types/some-lib.d.ts. The minimal "make it any" form (TypeScript's own second suggestion):

// src/types/some-lib.d.ts
declare module 'some-lib';

Better — a typed stub keeps real safety instead of opting the whole module into any:

declare module 'some-lib' {
  export function doThing(input: string): string;
  export interface Options {
    retries?: number;
    timeout?: number;
  }
  export const version: string;
}

Last resort — turn off the check#

// silences ALL of these, project-wide
{ "compilerOptions": { "noImplicitAny": false } }

Or // @ts-ignore on the import line. Both work and both are bad:

Decision guide#

Official references: Consuming declaration files, Type declarations, module .d.ts template, noImplicitAny.

Related Articles#

• TypeScript Migration Guide: Moving a JS Codebase in 2026
• Set a New Property on window in TypeScript
• Fix Next.js Build Error Module Not Found After Deploy
• Fix TS2305: Module Has No Exported Member in TypeScript
• Fix TS2564: Property Has No Initializer in TypeScript