not ignoring node_modules after explicitly setting --skipLibCheck flag and exclude

[CxGarcia]

TS version: 4.5.2
expected behavior: to ignore node_modules
actual behavior: doesn't ignore node modules

command:
$ tsc --skipLibCheck && vite build

log:

node_modules/react-dropzone-uploader/dist/Dropzone.tsx:504:44 - error TS2571: Object is of type 'unknown'.

504       console.error('Error Upload Params', e.stack)
                                               ~


Found 1 error.

error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

img log:

tsconfig:

  "compilerOptions": {
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true,
    "jsx": "react-jsx",
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "module": "ESNext",
    "moduleResolution": "Node",
    "noEmit": true,
    "noFallthroughCasesInSwitch": true,
    "downlevelIteration": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "target": "ES2015",
    "baseUrl": "./src",
    "paths": {
      "@components/*": ["components/*"],
      "@components": ["components"],
      "@views": ["views"],
      "@views/*": ["views/*"],
      "@guards/*": ["guards/*"],
      "@guards": ["guards"],
      "@api-client/*": ["api-client/*"],
      "@api-client": ["api-client"],
      "@store": ["store"],
      "@store/*": ["store/*"],
      "@helpers": ["helpers"],
      "@helpers/*": ["helpers/*"],
      "@snippets/*": ["_snippets/*"],
      "@services/*": ["services/*"],
      "@services": ["services"],
      "@customTypes/*": ["types/*"],
      "@customTypes": ["types"],
      "@hooks/*": ["hooks/*"],
      "@hooks": ["hooks"],
      "@assets": ["assets"],
      "@assets/*": ["assets/*"],
      "@router": ["Router"],
      "@router/*": ["Router/*"]
    }
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

[MartinJohns]

You're most likely including the source file in your project. exclude only acts as a filter on top of include, but imported files are always part of the compilation. You can use the --explainFiles compiler option to figure out why the file was included in the compilation.

This might be relevant to you: #30511

[RyanCavanaugh]

skipLibCheck means "Don't check .d.ts files any more than you have to". It doesn't mean "ignore .tsx files in node_modules".

[CxGarcia]

cool! many thanks for the support. will take a look and close the issue for now

[beinghaziq]

Hi, @CxGarcia have you resolved this issue?? I'm getting the same issue and I haven't reached any solution yet.

[CxGarcia]

hey @beinghaziq. yeah I decided to change libs and am now using react-dropzone since react-dropzone-uploader seems abandoned for over 2 years now

[beinghaziq]

Thank you very much 🙏

[felskov]

skipLibCheck means "Don't check .d.ts files any more than you have to". It doesn't mean "ignore .tsx files in node_modules".

Why not tho? I have a project using strict: true, but it breaks on some dependencies that have been developed without this same flag. These dependencies will type-check and build on their own without a problem, but my project fails on them because strict: true is enforced for their files as well.

I would very much like to use strict: true on my code only, and ignore checking of node_modules all together, as there is nothing I can do to fix errors nested in those files anyway - save perhaps reporting the issue, and hoping the authors will adjust their config and publish a new, complaint version.

Is there nothing I can do but to accept using a configuration that's compliant with my dependencies, and therefore restricting my ability to use strict rules in TypeScript? That seems like a design flaw in my eyes. Do you have other reasons for imposing this limitation? :)

[MartinJohns]

@felskov The correct approach for the package owner would be to release JavaScript and declaration files, not TypeScript files. See this comment: #44205 (comment) (it also mentions/links to the concerns and limitations regarding your suggestion.)

[felskov]

@MartinJohns Thanks for your feedback! :)

I agree, that the perfect solution in that particular case would be publishing with compiled JS files - unfortunately we don't always control third party packages. We can ask the authors nicely to compile TS to JS before publishing, but in the end we have no control over whether or not that happens. That can leave us with the choice of abandoning that dependency and either finding a new one or writing whatever it does ourselves -- or making our TypeScript config less strict to enable checking the dependency without errors, but negatively impacting type checks on our on code.

Another real-life example I've encountered with this, is within mono repos where you want to incrementally adapt stricter configurations of TypeScript. You setup each package with it's own tsconfig.json file, so configurations can be changed on a per-package basis. Everything works great, until the packages start depending on each other. You now risk having a scenario, where team A want to upgrade the tsconfig.json of package A with new stricter options. Unfortunately package A depends on package B, which is not yet compliant with these options. This leaves team A with the only option of requesting team B to adjust package B accordingly, and wait for them to finish doing so. Sometimes these dependencies cascade in very big repos, making it hard to update tsconfig.json without doing a full upgrade across the entire repo.

I understand from the comment you linked that the main concern is emitted files. In our case (and I think this reflects the reality in many new projects), TypeScript is not used as a compiler, only a type checker (ie. we always use --noEmit, and actual output is created by esbuild or similar).

To work around the issue on our end, I've created a tiny wrapper script to mimic running tsc --incremental --noEmit (it will read your tsconfig.json, but bear in mind that it doesn't currently accept any additional command line arguments). Before outputting the result, it will filter errors in all files outside of the project root and/or within a node_modules folder. This solves our specific issues as described above.

The script is available here:
https://gist.github.com/felskov/84fa477e87fb18f3ff7bee4ee2ce1c57

If we suppose that type-check.mjs, package.json and tsconfig.json are all located at the root of your project, you would then configure it by adding the following script to package.json:

{
  "scripts": {
    "type-check": "./type-check.mjs"
  }
}

And then run the type-check script from anywhere within your project folder:

npm run type-check

Do you have any thoughts about using such a script or any feedback to the implementation?

[danielschnetler]

I was facing the issue with node_modules not being excluded after upgrading node to 18.4.0 LTS
Turned out tsc -v was still showing the previous version.
Just closing the terminal and reopening it resolved the issue for me! i.e. reloading the environment variables

[RobRendell]

I'm having similar issues, where I have stricter options set in my tsconfig.json (noFallthroughCasesInSwitch and noUncheckedIndexedAccess) than the dependency does in its. However, what's interesting is that the dependency (@streamparser/json) actually does export javascript and .d.ts files in its dist folder, and its package.json references those files:

  "main": "./dist/mjs/index.js",
  "module": "./dist/mjs/index.js",
  "browser": "./dist/mjs/index.js",
  "types": "./dist/mjs/index.d.ts",

However, because it also bundles its src folder with .ts files inside, Typescript is trying to redundantly typecheck those files anyway, forcing me to remove my stricter tsconfig options if I want to build. In case it makes a difference, I'm running tsc --noEmit.

[robert-melonn]

@MartinJohns Thanks for your feedback! :)

I agree, that the perfect solution in that particular case would be publishing with compiled JS files - unfortunately we don't always control third party packages. We can ask the authors nicely to compile TS to JS before publishing, but in the end we have no control over whether or not that happens. That can leave us with the choice of abandoning that dependency and either finding a new one or writing whatever it does ourselves -- or making our TypeScript config less strict to enable checking the dependency without errors, but negatively impacting type checks on our on code.

Another real-life example I've encountered with this, is within mono repos where you want to incrementally adapt stricter configurations of TypeScript. You setup each package with it's own tsconfig.json file, so configurations can be changed on a per-package basis. Everything works great, until the packages start depending on each other. You now risk having a scenario, where team A want to upgrade the tsconfig.json of package A with new stricter options. Unfortunately package A depends on package B, which is not yet compliant with these options. This leaves team A with the only option of requesting team B to adjust package B accordingly, and wait for them to finish doing so. Sometimes these dependencies cascade in very big repos, making it hard to update tsconfig.json without doing a full upgrade across the entire repo.

I understand from the comment you linked that the main concern is emitted files. In our case (and I think this reflects the reality in many new projects), TypeScript is not used as a compiler, only a type checker (ie. we always use --noEmit, and actual output is created by esbuild or similar).

To work around the issue on our end, I've created a tiny wrapper script to mimic running tsc --incremental --noEmit (it will read your tsconfig.json, but bear in mind that it doesn't currently accept any additional command line arguments). Before outputting the result, it will filter errors in all files outside of the project root and/or within a node_modules folder. This solves our specific issues as described above.

The script is available here: https://gist.github.com/felskov/84fa477e87fb18f3ff7bee4ee2ce1c57

If we suppose that type-check.mjs, package.json and tsconfig.json are all located at the root of your project, you would then configure it by adding the following script to package.json:

{
"scripts": {
"type-check": "./type-check.mjs"
}
}
And then run the type-check script from anywhere within your project folder:

npm run type-check
Do you have any thoughts about using such a script or any feedback to the implementation?

👏👏👏👏 @felskov you ve told everything. Even trying to fix this with ts project references is a nightmare and not sure if the best solution. There is another case besides yours. When app1 and app2 depend on lib1 in a monorepo, you re going to have issues if app1 is strict and app2 is not. Both of them will check lib1 with their tsconfigs and this will fail. Lib1 have to satisfy both configs. What a nightmare work with typescript :/.