How to force tsc to ignore node_modules folder?

Question

I'm using tsc build tasks. Unfortunately I'm always getting the same errors from the node modules folder

Executing task: .\node_modules\.bin\tsc.cmd --watch -p .\tsconfig.json <
node_modules/@types/node/index.d.ts(6208,55): error TS2304: Cannot find name 'Map'.
node_modules/@types/node/index.d.ts(6215,55): error TS2304: Cannot find name 'Set'.
node_modules/@types/node/index.d.ts(6219,64): error TS2304: Cannot find name 'Symbol'.
node_modules/@types/node/index.d.ts(6225,59): error TS2304: Cannot find name 'WeakMap'.
node_modules/@types/node/index.d.ts(6226,59): error TS2304: Cannot find name 'WeakSet'.
10:13:18 - Compilation complete. Watching for file changes.

I already added the directory to the ignore at tsconfig.json


    {
      "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "sourceMap": true,
        "strict": false,
        "noImplicitAny": false,
        "strictPropertyInitialization": false,
        "esModuleInterop": true,
      },
      "include": [
        "src/*"
      ],
      "exclude": [
        "node_modules",
        "./node_modules",
        "./node_modules/*",
        "./node_modules/@types/node/index.d.ts",
      ]
    }

What I'm doing wrong? What should I do in order to ignore those errors?

I'm using VsCode and tsc Version 2.9.2

This could be helpful: **"...To do so, the compiler needs the definition of a module, this could be a .ts file for your own code, or a .d.ts for an imported definition file. If the file was found, it will be included regardless of whether it was excluded in the previous steps or not."** -> https://github.com/Microsoft/TypeScript/wiki/FAQ#why-is-a-file-in-the-exclude-list-still-picked-up-by-the-compiler — Adam Cooper, May 18 '21 at 16:04
I want types. I don't want to have to build my project. To do that, I'm using JSDoc, since it uses comments that runners will ignore. The only CLI I could find that could lint my types against the JSDoc is the Typescript CLI with "noEmit": true and "checkJs": true. But then I'm getting errrors from node_modules/utils/utils.js. I don't want theese errors. How can I remove them? — RedGuy11, May 18 '21 at 21:27
[Restarting the IDE](https://stackoverflow.com/questions/62273153/this-module-is-declared-with-using-export-and-can-only-be-used-with-a-defau/62275620#62275620) or already `F1 → TypeScript: Reload Project` in VSCode helped to make some Reported Problems disappear — cachius, Apr 06 '23 at 10:09

score 430 · Answer 1 · answered Aug 26 '19 at 07:28

430

Quickfix is to skip the check

{
  "compilerOptions": {
    "skipLibCheck": true
  },
}

answered Aug 26 '19 at 07:28

Daniel Swiegers

4,631
1
8
13

2

This worked since the library I was importing was exporting just the types of its own and I was importing the actual files by using script imports so that i can serve them from cdn. Thanks :) – acesmndr Jan 17 '20 at 05:50
9

Docs for this: https://www.typescriptlang.org/docs/handbook/compiler-options.html – jocull Mar 13 '20 at 16:41
1

Works for me with v3.9.7 – heyomi Jul 31 '20 at 18:20
13

This will also skip your type checking of all declaration `*.d.ts` https://dd.engineering/blog/typescript-the-skiplibcheck-option-explained – Gianfranco P. Jan 07 '21 at 13:40
5

does skipLibCheck only target the node_modules folder ? – Dilip Agheda Mar 29 '21 at 03:48
37

@DilipAgheda no it will also target any `d.ts` files outside of `node_modules`. So it is probably not what most people want. – KevinH Apr 06 '21 at 14:42
2

Note that `tsc --listFiles` seems to ignore this argument, it will still display node_modules typings (TS 4.2). – Eric Burel Jun 14 '21 at 11:57
1

@GianfrancoP.Apparently it will **not** completely disable .d.ts files. Any types your code reaches directly will still be included from those files. Only .d.ts files as a whole won't be checked any more. -- https://dd.engineering/blog/typescript-the-skiplibcheck-option-explained – Mörre Jul 22 '21 at 16:52
Didn't work for version 3.3.x but worked after i upgraded to v4.5 – jtlindsey Aug 07 '21 at 22:12
1

This doesn't work if you have `checkJs` enabled and a node module contains js files. – Jespertheend Dec 09 '21 at 17:02
This absolutely does NOT work. I've been banging my head against this for weeks. If you include a module, it gets checked, and there appears to be no way to stop this from happening. – ipmcc May 01 '22 at 18:03
Explanation of what `skitLibCheck` does: https://www.typescriptlang.org/tsconfig#skipLibCheck – shen May 07 '22 at 01:26
2

[Better answer](https://stackoverflow.com/a/54277766/4410590) that only ignores `node_modules`: set `types=[]`. – victorlin Apr 08 '23 at 00:02

score 66 · Answer 2 · edited Mar 11 '23 at 03:31

Add an empty "types" option in "compilerOptions":

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "sourceMap": true,
    "strict": false,
    "noImplicitAny": false,
    "strictPropertyInitialization": false,
    "esModuleInterop": true,
    "types": []
  },
  "include": [
    "src/*"
  ],
  "exclude": [
    "node_modules",
    "./node_modules",
    "./node_modules/*",
    "./node_modules/@types/node/index.d.ts",
  ]
}

From https://www.typescriptlang.org/tsconfig#typeRoots

@types, typeRoots and types

By default all visible “@types” packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible; specifically, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

...

Specify "types": [] to disable automatic inclusion of @types packages.

Keep in mind that automatic inclusion is only important if you’re using files with global declarations (as opposed to files declared as modules). If you use an import "foo" statement, for instance, TypeScript may still look through node_modules & node_modules/@types folders to find the foo package

@MichaelOzeryansky: sorry, I don't understand your point. I just added one line to the tsconfig.json of the OP — Mic, Mar 27 '20 at 08:38
@MichaelOzeryansky this addition would probably make your compile run faster. More lines does not automatically make compile time slower. Less lines does not make your code run faster. The caveat here is that this would prevent many projects from compiling without other significant changes due to no longer including types they need. — SgtPooki, Dec 31 '20 at 00:38
Specifying an empty list for CLI worked for me like this `tsc ./myfile.ts --types --someOtherOption` — Anton Belonovich, Apr 28 '23 at 21:19

score 64 · Answer 3 · answered Mar 11 '21 at 08:34

64

You can do this right on the command line

tsc --skipLibCheck

answered Mar 11 '21 at 08:34

Klas Mellbourn

42,571
24
140
158

this is better because at least the library types are validated during the webpack build if you're using webpack plugins to validate the included library types – scott dickerson May 25 '21 at 16:18
This worked for me (TS 4.4.4). Even though I had also had it specified in the tsconfig, apparently I explicitly needed to do it like your solution.. – Sander Looijenga Nov 04 '21 at 11:40
2

EDIT: Regarding my comment above; I didn't RTFM, I specified a file in my `tsc` command, which, as is clearly stated in the docs, will ignore the tsconfig; https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#using-tsconfigjson-or-jsconfigjson – Sander Looijenga Nov 04 '21 at 12:54

score 45 · Answer 4 · edited Apr 06 '22 at 03:53

45

I met this issue with typescript@3.2.1 and fixed by upgrading it to 3.7.3.

Notice with typescript@3.2.1, the skipLibCheck does not take effect. When I upgraded TypeScript the skipLibCheck: true works.

edited Apr 06 '22 at 03:53

Community

1
1

answered Dec 05 '19 at 12:38

Jeff Tian

5,210
3
51
71

9

was helpful, upgraded to latest. 3.9.7 and added skipLibCheck – user1769790 Aug 04 '20 at 18:29
1

cool update ts version – Sun Dec 14 '21 at 08:58

score 42 · Answer 5 · answered Apr 29 '21 at 23:10

42

set "skipLibCheck": true inside tsconfig.json

answered Apr 29 '21 at 23:10

Dastan

1,929
2
10
21

score 8 · Answer 6 · answered May 26 '22 at 13:38

8

I had a similar issue in a monorepo using yarn workspaces.

Turned out my app was using a different TypeScript version to the root workspace and bringing those in sync fixed the issue.

You can verify this in your own repo by running yarn list typescript or npm ls typescript.

If you have multiple versions of TypeScript then upgrade your projects with the lower version so that all have the highest version currently in use in your repo, e.g. yarn add -D typescript@4.5.5 (or whatever version you need)

answered May 26 '22 at 13:38

HNipps

456
3
15

2

Yes. Nothing else seemed to work for me, but this one did. Thanks! – VaibhavJoshi Jul 22 '22 at 10:58
2

This is the only solution that works for me, I had different version on my global and my local – BlaShadow Aug 28 '22 at 18:27
1

Same issue but with npm workspaces. Thank you! – JoshStrange Jan 08 '23 at 04:11

Mikael Dahlgren · Answer 7 · 2022-10-12T10:28:36.907

if you are here and none of the following has worked for you:

❌ Updgrade/downgrading typescript version (NOTE: When you run the tsc command, the globally installed typescript version is used as the compiler. So even if you have the latest typescript version in your package.json, you will have to upgrade typescript globally. With npm thats npm install typescript@latest -g )
❌ Adding/Editing tsconfig options: target, types, include, exclude, allowJs, skipLibCheck
❌ npm update
❌ Deleting node_modules && npm i
❌ Deleting package-lock (don't do that btw) && npm i

I want to leave this link from the typescript config docs here for you: What does this("types") affect?

With this knowledge, this solved the issue for me:

See what module is causing the error in the log when you run tsc. (For me it was node_modules/mongoose/types/*, so mongoose was the culprit.)
Convert all your ES6 imports of this module to commonjs's require(). (In my case import mongoose from 'mongoose' --> const mongoose = require('mongoose') )

I hope this solves your issue

Mehdi Benhamouche · Answer 8 · 2023-01-20T20:33:40.850

4

Upgrade your typescript & ts-node: "typescript": "4.9.4" "ts-node": "10.9.1"

and use the flag --skipLibCheck when you build or put it in the compilerOtions on the tsconfig.json file ("skipLibCheck": true)...

edited Jan 20 '23 at 20:33

answered Jan 19 '23 at 22:42

Mehdi Benhamouche

61
3

score 3 · Answer 9 · answered May 31 '22 at 17:45

3

This is random but none of the solutions here worked. I had an error occuring in a node_module and what fixed it was this:

Changing: target: "esnext"

To any specific version, e.g.: target: "es2020"

In case it helps some other poor traveller ‍♂️

answered May 31 '22 at 17:45

Dominic

62,658
20
139
163

NotX · Answer 10 · 2023-07-14T10:54:57.850

3

Happened for me b/c I accidentally imported something from a library with was not part of the public API. E.g. the import { ValidationErrorCode } from '@apollo/server/src/plugin/schemaReporting/generated/operations'; caused tsc to report type errors in @apollo/server. Importing from src/ or dist/ should always be a red flag.

edited Jul 14 '23 at 10:54

answered Jul 14 '23 at 10:47

NotX

1,516
1
14
28

This was my issue, I was importing types not otherwise output by `react-map-gl` and forgot about it, causing this issue. Thanks for being spot on for me, was pulling my hair on this one. – ShaneTheKing Aug 22 '23 at 10:57

score 2 · Answer 11 · answered May 07 '22 at 20:37

If you find yourself here and none of the other answers is solving the problem, check to make sure that you haven't set maxNodeModuleJsDepth. If you have allowJs enabled this option lets TypeScript attempt to infer types from modules in node_modules, and skipLibCheck doesn't have any effect on that, because it's reading javascript files and not type declarations. The default setting for maxNodeModuleJsDepth is 0, and in the vast majority of cases that's what you want (and you should prefer using @types packages instead of turning this on).

score 1 · Answer 12 · answered Aug 03 '23 at 18:27

Why not specify the types root, this way the parent "../node_module", "../../node_modules:" etc. will be ignored and only local types will be taken.

"typeRoots": ["./node_modules/@types"]

PS This was not working for me in my case only the above approach.

"skipLibCheck": true

How to force tsc to ignore node_modules folder?

12 Answers12

Linked