Fix Cannot find type definition file for 'body-parser'

TL;DR#

Cannot find type definition file for 'body-parser' with the reason Entry point for implicit type library 'body-parser' means a folder node_modules/@types/body-parser exists but holds no declaration file. Before TypeScript 6.0, a tsconfig.json without a types field loads every folder under node_modules/@types, so one empty or half-deleted folder fails the build even if your code never touches body-parser. Run npx tsc --noEmit first. If it fails, delete the folder and run npm install. If it passes, the problem is in the editor: point it at the workspace TypeScript, then run TypeScript: Restart TS Server.

The error#

The Stack Overflow question behind this page shows the error six times on tsconfig.json at line 1, column 1, in a React project:

Cannot find type definition file for 'body-parser'.
  The file is in the program because:
    Entry point for implicit type library 'body-parser'

The two highest-voted answers say to restart VS Code. That works in one situation and does nothing in the other, so it helps to know which one you are in. The same error, reproduced from the command line with TypeScript 5.9.3 on Node 22 (official node:22-alpine image, 22 October 2026), in a one-file project with an empty node_modules/@types/body-parser folder:

$ npx tsc -p .
error TS2688: Cannot find type definition file for 'body-parser'.
  The file is in the program because:
    Entry point for implicit type library 'body-parser'
[exit 2]

No source file and no line number are printed: the error is about the program, not about a line of code, which fits the editor showing it on tsconfig.json at 1:1.

Why it happens#

The reason line is the clue. "Implicit type library" means nobody asked for body-parser: no import, no /// <reference types>, no entry in compilerOptions.types. TypeScript added it on its own.

The types reference describes the rule: "For versions below TypeScript 6.0, by default all visible "@types" packages are included in your compilation." Visible means any package in node_modules/@types of the project folder or of any parent folder.

The compiler source shows what "package" means here. In TypeScript 5.9.3, getAutomaticTypeDirectiveNames returns the types list if you set one. Otherwise it walks each type root and adds every directory name it finds. It does not check whether the directory contains a .d.ts file. It skips only two kinds of folder: names that start with a dot, and folders whose package.json has "typings": null (the comment there says types-publisher "sometimes creates packages with "typings": null for packages that don't provide their own types"). Every name on that list then has to resolve to a declaration file, the same way a type package you list yourself does. When nothing is found, you get TS2688 for that name, once per broken folder. In the reproduction, a second empty folder @types/express produced a second, identical error for express. Several folders can fail at once, so seeing the error more than once is expected when more than one folder is broken.

That also explains why a React project has body-parser types at all. react-scripts 5.0.0 depends on webpack-dev-server ^4.6.0, and webpack-dev-server 4.7.4, released on 2 February 2022, lists "add @types/express" among its bug fixes. The @types/express package in turn depends on @types/body-parser. So a dev-server dependency places the folder in node_modules/@types, and the compiler includes it in your app's program.

The reproduction also confirmed the skip rule. The same empty folder with only a package.json containing "typings": null passed with exit 0.

Fix#

1. Ask the command-line compiler, not the editor#

npx tsc --noEmit -p .

If the CLI fails with the same TS2688, the folder on disk really is broken, and no editor action will help. Go to step 2.

If the CLI passes but the editor still shows the error, the editor's TypeScript is the odd one out. This page did not reproduce editor behaviour, so here are the two checks to make, in order:

1. Which compiler the editor runs. VS Code ships its own TypeScript and, since version 1.9, "will no longer automatically load versions of TypeScript" from a workspace setting without asking. After a compiler upgrade the two can differ, and the table further down shows that 5.x and 6.0+ disagree on exactly this error. With a .ts file focused, run TypeScript: Select TypeScript Version... and choose Use Workspace Version.
2. A restart of its language server. The top answer on the question reports the error after a TypeScript update, gone after relaunching VS Code. You do not need to relaunch the whole editor: run TypeScript: Restart TS Server.

The extension lists both commands in the Command Palette only when its typescript.isManagedFile condition holds, so focus a .ts file rather than the tsconfig.json tab first. The titles and that condition come from the package manifest of VS Code's TypeScript extension and its labels file.

2. Look inside the folder and find who installed it#

ls -la node_modules/@types/body-parser
npm ls @types/body-parser

An empty listing, or one without index.d.ts, confirms the cause. npm ls tells you which package wants it. In a project where @types/express pulled it in and the folder was emptied, the reproduction printed the parent and a blank version:

work@1.0.0 /work
`-- @types/express@5.0.6
  `-- @types/body-parser@

A folder that no package needs is marked as a leftover instead. For a stray empty @types/cors folder, which failed tsc in the same way, the output was:

work@1.0.0 /work
`-- @types/cors@ extraneous

When several names fail at once, list every folder under node_modules/@types that has no declaration entry point:

for d in node_modules/@types/*/; do
  if ls "$d"*.d.ts >/dev/null 2>&1; then continue; fi
  if grep -Eq '"(types|typings)"' "${d}package.json" 2>/dev/null; then continue; fi
  echo "no declaration entry: $d"
done

On a test fixture, it flagged the empty body-parser folder and a stub minimatch folder. It skipped a folder with index.d.ts and one with "typings": null. A stub is not always broken (see below), so treat the output as a list to check, not a list to delete.

3. Delete the broken folder and reinstall#

rm -rf node_modules/@types/body-parser
npm install

The reproduction ran this with @types/body-parser installed both directly and as a dependency of @types/express. In both cases npm install reported "added 1 package", the restored folder contained index.d.ts, and tsc passed. For the extraneous @types/cors folder, deleting it was enough. If several folders are broken, deleting the whole node_modules folder before npm install is the blunter version of the same step.

4. Or stop the automatic loading with an explicit types list#

On 5.9 and earlier, any types list turns the directory walk off (on 6.0 and later, any list without "*"). With "types": [] and the empty folder still in place, the reproduction passed:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "commonjs",
    "strict": true,
    "noEmit": true,
    "types": []
  },
  "include": ["src"]
}

This also drops any global types you were relying on, such as process from @types/node or describe from a test runner. List those by name, for example "types": ["node", "jest"]. If console or process stop resolving after this change, Cannot find name 'console' in TypeScript covers the lib and types combinations that cause it. Modules you import still get their @types package. As the reference puts it, the option "does not affect how @types/* are included in your application code".

Verify the fix#

Run the compiler again, then confirm that nothing is being pulled in implicitly from a broken folder:

npx tsc --noEmit -p .
echo "exit $?"
npx tsc --noEmit -p . --explainFiles | grep -B1 "implicit type library"

The first command must exit 0. The last one prints, for every package the compiler still loads implicitly, the reason line and the file above it. Every line should point to a real .d.ts file. Then restart the TS server once so the editor matches the CLI.

TypeScript 6.0 and 7.0 changed the default#

The types reference now begins: "By default types is set to []." In 6.0.3, getAutomaticTypeDirectiveNames returns your types list unchanged unless it contains the wildcard "*". Only the wildcard walks node_modules/@types. The same empty-folder project gave these results:

So on 6.0 and later, this error with the "implicit" reason only appears if someone added "*" to restore the old behaviour. The console page covers why "*" fails on 5.9 and which other globals the new default drops. Other 6.0 breaking defaults are in the TypeScript 6.0 migration guide for Next.js and Supabase.

The reason line also changes when you name the package yourself. With "types": ["body-parser"] on 6.0.3 and the same empty folder, the compiler printed:

error TS2688: Cannot find type definition file for 'body-parser'.
  The file is in the program because:
    Entry point of type library 'body-parser' specified in compilerOptions

"Implicit type library" means a folder was picked up by the directory walk. "Specified in compilerOptions" means your own types list names a package that is not installed. The second case needs npm install --save-dev @types/body-parser or the name removed from the list, not a folder cleanup.

When a deprecated stub @types folder is the culprit#

Some @types packages are now stubs. @types/minimatch 6.0.0, published in July 2025, is deprecated with "This is a stub types definition. minimatch provides its own type definitions, so you do not need this installed." Its tarball contains only LICENSE, README.md and package.json, with no .d.ts, and the package does not set "typings": null. The directory walk therefore includes it.

On TypeScript 5.9.3 this stub alone did not fail. It depends on minimatch itself, and --explainFiles showed the implicit minimatch library resolving to the real package's declarations:

node_modules/minimatch/dist/commonjs/index.d.ts
  Entry point for implicit type library 'minimatch' with packageId 'minimatch/dist/commonjs/index.d.ts@10.2.6'

Once node_modules/minimatch was removed and the stub folder stayed, the familiar error came back:

error TS2688: Cannot find type definition file for 'minimatch'.
  The file is in the program because:
    Entry point for implicit type library 'minimatch'

A stub folder is harmless as long as the real package is installed at the top of node_modules, as it was in the passing run. If the error names a package whose @types entry is a stub, run npm uninstall @types/<name> when it is a direct dependency. If something else installs the stub, npm ls @types/<name> shows what; until that dependency drops it, an explicit types list (step 4) keeps the compiler away from the folder.

This page covers folders the compiler loads without being asked. When the error names a module you import yourself and says it has no declaration file, that is TS7016, covered in Could not find a declaration file for module. A folder under node_modules/@types can also break a much older compiler in a different way: TS1084 Invalid 'reference' directive in @types/node shows a newer @types/node loaded into TypeScript 2.x. If fixing this page's error with an explicit types list makes console or process disappear, the next stop is the console page linked above. Above all, use npx tsc --noEmit before reaching for an editor restart. It tells you in one command whether the problem is on disk or only in the editor.