Repository navigation
Disable type checking for node_modules entirely #40426
Description
Activity
As a user of this library I want to be able to disable type checking for a library (or all) because I trust this library has been tested enough in other ways.
Okay, this is one of the reasons you might use
skipLibCheck.I had the case that a library came with a
dist/folder and almost all types were perfectly arranged in .d.ts files. But one file was making an import from../index.d.ts(which seems to be for development purposes, the lib main file isdist/index.d.ts) which in turn then importedsrc/ClassA.tsThis is the opposite of the scenario you're describing. The library author has shipped incoherent types, and who's to say what the correct interpretation of that is? It is good that TypeScript errors here, even if it is an overall terrible user experience.
"Disabling type-checking" can mean a lot of things. Having the package come in as
anyis one possibility. If that's what you're looking for, then you can add a single global file withdeclare module "incorrectly-authored-library";until the package ships correct types. Otherwise, I'm not sure what you might have in mind.Reacted by Alexander “weej” Jones, Erik Arvidsson and Emmanuel Meric de BellefonReacted by Zach Hardesty, April Mintac Pineda, Lanthier-Labs, Aiden Liu, MioQuispe, wepsree, Michael Barney, Jr, Adam Spiers, JacobDel, David Kensche and 21 moreI want to mention after reading this a second time: shipping
.tsfiles is generally nice when using--declarationMapsbut I don't know how to best address the issue of different settings between your project and the library's project. Figuring out good prescriptive advice for doing that might be one strategy here.Yeah there are lots of good reasons to actually have the sources of a library available, I like to explore them in my IDE sometimes or maybe while debugging etc.
But I don't actually want to have them checked by the typescript compiler, hence the skipLibCheck. It's just so confusing to me why the skipLibCheck is only intended for typing files and not for
.tsfilesReacted by JacobDel, David Kensche, Samuel R., Spence, Russell McClellan, Kevin Fleischman, Neli Harbuzava, Roman Jámbor, Stein Strindhaug, Onyedikachi Ozoani and 1 moreThis scenario is going to be completely busted for a lot of reasons. It seems like the option one would really want, if they found themselves stuck in it, would be to say that
.tsfiles under some given paths should be treated as if they were.d.tsfiles (don't emit, don't typecheck underSLC, don't use to computerootDir, etc) but have their implementations used for inference. That said, this is just critically a misconfiguration and it's possibly counterproductive to do gymnastics to make it work.I think
.tsfiles imported by.d.tsfiles should be treated the same way, so if skipLibCheck is enabled it should ignore them.If you are importing
.tsfiles from actual source files likedist/main.jsimporting../src/ClassB.tsthen i just expect it to break. That shouldn't be ignored.Reacted by Feranmi Akinlade and AudiopolisCould there be a way to just silence errors from certain paths?
I don't want to make a whole import from node_modules type
anyas 99% of the types are fine and are useful for code completion, but I don't want to hear about the 1% of types that don't adhere to my tsconfig when I can't do anything about them (aside from fork the whole module for the sake of a couple of errors).Noting that a single type check fail would break CI unless I silence it some how.
Reacted by nitram, Jesper van den Ende, Pengő Dzsó, wepsree, knackstedt, Kier Borromeo, Michael Barney, Jr, Adam Spiers, David Kensche, David Lozic and 13 more(I tried
@ts-ignoreabove the import with the issue, but the errors are with certain files in that imported module, so obviously didn't work)I am having a very similar issue with a node_module that is included locally in package.json with a path:
file:.... there are type errors happening inside of that library and the compiler does not ignore them despite having"skipLibCheck": truein the config.Reacted by Samuel R., Jo Wo, m1212e, Kenneth Pirman and Neli HarbuzavaI had the case that a library came with a dist/ folder and almost all types were perfectly arranged in .d.ts files. But one file was making an import from ../index.d.ts(which seems to be for development purposes, the lib main file is dist/index.d.ts) which in turn then imported src/ClassA.ts
The library author used a different tsconfig and didn't use strict type checking, but I do and that's why the type check fails for me, because now the typescript source files of the library author are type checked.
Just ran into this exact scenario trying to type check my build scripts. Seems like not many people do that so some build-related modules have issues that go unnoticed.
- added a commit that references this issue
on Aug 20, 2021 Here's an example of a project that seems to be doing something benign, simply importing an interface for the sake of type checking. But the import path points to distributed typescript source files rather than the compiled JS. And while there aren't any issues with the types of that module, because my project has stricter type check settings it causes issues.
https://github.com/underfin/vite-plugin-vue2/pull/125/files
Reacted by nitram, Joe Harvey, Joseph Bradley Barnes and Onyedikachi Ozoani- added a commit that references this issue
on Aug 21, 2021 - added a commit that references this issue
on Oct 29, 2021 50 remaining items
I don't understand what the argument would be for not allowing the programmer to prevent type checking of node_modules. Honestly it is completely obvious that this should be supported.
When you have people disabling strict type checking and the use of type declaration files your design idea isn't working. Instead of assuming people are incapable of using tools properly, assume they are intelligent and provide them the tools.Can't use verbatimModuleSyntax atm if even one package has a bad setup import
I have the same issue. As soon as I turned on verbatimModuleSyntax, it started type checking dependencies.
Mo (@hematy61) Probably you have an unused import that was previously being trimmed via the default "Import Elision" behavior. VMS turns that off.
If you trim it manually (delete the line, delete the binding, or mark the import/binding with
type) then you should restore the original scope of the checker.After trying this, if you still find that VMS increases the scope of the checker, please provide a minal repro. Because I think that would be new information and potentially a bug.
Ryan Cavanaugh (@RyanCavanaugh)
Can people post "Here's how I ended up importing .ts files from node_modules" or "Here are the errors in a .d.ts in node_modules I had" instead of "same" ?
This is a real and easily reproducible problem. You're not intentionally importing TypeScript - you're simply installing a package that includes a .ts file listed under the
typesfield inpackage.json. There are packages out there doing this, and the number is growing due to support for runtimes like Deno and Bun.Consider a package with the following
package.json:package.json
{ "name": "incriminated-package", "types": "index.ts", // <==== this !! "module": "dist/index.js", "type": "module", "files": [ "dist/index.js", "index.ts" ] }
If that linked .ts file is less strict than your own codebase, you're in trouble. Why did someone publish a .ts file alongside the compiled JS instead of a .d.ts file? There are multiple reasons:
- To support Deno, Bun, and other runtimes that natively use .ts.
- It's sometimes impossible to generate .d.ts files due to limitations in certain bundlers. You might need specific plugins, and they don’t always work - especially with complex setups involving multiple exports, or when the folder structure of dist/ differs significantly from src/.
DEMO here, live example here on stackblitz.
Error:
node_modules/incriminated-package/index.ts:2:5 - error TS2322: Type 'null' is not assignable to type 'string'. 2 property: string = null; ~~~~~~~~ Found 1 error in node_modules/incriminated-package/index.ts:2The TypeScript file is not used during compilation or at runtime - only the JavaScript is. I mean, that TS has no real impact on project but typechecking. So why does this error matter when skipLibCheck is enabled? TypeScript doesn’t use that code; it doesn’t bundle it or execute it in any way.
Why can't it be ignored the same way .d.ts files are? If there's a valid scenario where it does matter, then maybe the solution is to introduce a separate config option - something like skipLibTsCheck?! It will not break anything and quite a lot of people want this for 5 years!
Reacted by Talaver Oleh, Stein Strindhaug, Rafael Rodrigues, Onyedikachi Ozoani, Kim Joshua C. Advincula, Ramprakash, Julien Habert and Anne Klapwijkanother example of
.tsfiles (advertently or not) being included in thetypesfield which will cause errors in stricter codebases.(no hate to the authors! it's a good library)
I'd also welcome it if we could ignore node_modules errors per se, and/or have
skipLibCheckalso skip non-node_modules.d.tsfiles is pretty annoying. But I also stumbled upon something else:I tried the suggested strategy outlined by Daniel,
declare module 'whatever'to overwrite wrong typinges, but that doesn't if you're- using JS, not TS, but strict type checking
- using
jsconfig.json, nottsconfig.json - pass the
jsconfig.jsontotscusing-poption - the library ships as js files only
Example:
npm install vue-virtual-scroller, import it in a.jsfile, setstrict: trueinjsconfig.json, runnpx tsc --noEmit -p jsconfig.jsonand see errors that are impossible to get rid off, regardless of any extra.d.tsfiles you put in the directory.I don't really know what's going on and the type check output seems also to be pretty different with jsconfig, but the solution is simple:
Rename
jsconfig.jsontotsconfig.json.Maybe it's a bug. But my past experience in reporting bugs has been that everything is always working as intended and it's my misunderstanding at fault 😄. On an unrelated note though, it's so refreshing to see core TS contributors on GH issues debating with the community over and over and keep explaining and arguing even after years. This must be exhausting AF, but it's one of my favorite aspects about the language.
- added a commit that references this issue
on Jun 29, 2025 Any solution here? I just want to simply exclude a folder from types
Reacted by Israel Antonio Rosales LaguanIt's almost 5 yrs now. Ryan Cavanaugh (@RyanCavanaugh) Please 🙏 add the feature.
Reacted by Dariusz Rumiński, Kim Joshua C. Advincula, Anne Klapwijk and Sohel Islam ImranIt is clear that without taking types from node_modules, all packages that have been used and provide return values into user code will be "disconnected" and lead to no type checking on the function calls, on returned types and derived values, which can be a lot.
So it makes perfect sense to keep reading types from node_modules.
What does not make sense is to bark at every type issue in packages in node_modules, which could be a huge pollutant of the logs.
I sense that everyone coming to this issue simply wants to silence all the warnings and (maybe optionally) errors from node_modules, as they simply create a ton of noise, but are not actionable and not fixable (in a sense that 3rd party packages are not under user control).
What if there were an option "silence node_module type check messages" with 3 choices - show all (errors and warnings), show only errors, and hide/ignore all errors and warnings. Regardless of that setting, types that can be used from the node_modules packages should propagate through the type checking process. The ones that are broken or not useable, will be quietly ignored if setting asks for it. Default, if not specified, of course, should be like it is currently behaving - report all issues, so there are no surprises.
Reacted by JeffReacted by Onyedikachi Ozoani, Dariusz Rumiński, Bogdan Tikho, Alek Mikucki, Kim Joshua C. Advincula, Tomasz Sapeta, Anton Honda, Marko Bonaći, Jeff, Erik Rasmussen and 4 moreIt is clear that without taking types from node_modules, all packages that have been used and provide return values into user code will be "disconnected" and lead to no type checking on the function calls, on returned types and derived values, which can be a lot.
So it makes perfect sense to keep reading types from node_modules.
What does not make sense is to bark at every type issue in packages in node_modules, which could be a huge pollutant of the logs.
I sense that everyone coming to this issue simply wants to silence all the warnings and (maybe optionally) errors from node_modules, as they simply create a ton of noise, but are not actionable and not fixable (in a sense that 3rd party packages are not under user control).
What if there were an option "silence node_module type check messages" with 3 choices - show all (errors and warnings), show only errors, and hide/ignore all errors and warnings. Regardless of that setting, types that can be used from the node_modules packages should propagate through the type checking process. The ones that are broken or not useable, will be quietly ignored if setting asks for it. Default, if not specified, of course, should be like it is currently behaving - report all issues, so there are no surprises.
This is exactly what we need. Good reasoning.
Reacted by Aral BalkanToday I encountered the behavior that tsc insists in doing error checking for node_modules that publish .ts sources, even with node_modules excluded and skipLibCheck set. I would like a way to disable that behavior.
Reacted by Andrzej Wódkiewicz, Pentadome, Andrii Oriekhov and Yasser GreyebI needed to import a .ts file from a node module and now i get typescript errors from that file. Why can't we set paths where we don't want type checking?
Reacted by Andrii Oriekhov and Yasser Greyebnodejs can run (some) .ts files natively, but it won't load .ts files from node_modules, based largely on arguments from the typescript team that if node allowed .ts files in node_modules folks would publish .ts only packages to npm, which could cause performance issues for
tscas processsing .ts files is slower than .d.ts, and introduces nuance of tsc version and tsconfig settings.
Jake Bailey (@jakebailey) Ryan Cavanaugh (@RyanCavanaugh)
I buy those arguments, but they convince me that typescript should implement this feature - not type checking .ts files in node_modules - not that node should support type stripping in node_modules.I setup a fresh tsc 5.9 project and wrote a module in node_modules/foo with .ts and .d.ts files, and typescript always preferred the .ts files instead of .d.ts files. TypeScript should have a recommended or default option to prefer .d.ts files, or ignore all .ts files in node_modules. That should fix the potential performance issue, and allow node to support type stripping in node_modules.
Folks can ship libraries with .ts to run and .d.ts files for type checks.Reacted by Roman Jámbor, Elliot Shepherd and Eli- added a commit that references this issue
on Jul 2, 2026
Search Terms
skipLibCheck
node_modules
ignore library
exclude
Suggestion
Either a new option or the existing option
skipLibCheckshould be able to disable type checking for node_modules.Use Cases
A library author might have a faulty import or might only provide typescript files for his library and not transpiled code. As a user of this library I want to be able to disable type checking for a library (or all) because I trust this library has been tested enough in other ways.
Another issue where I found a library shipping ts files and causing errors for the user: #15363
The response at the end is very relevant
Originally posted by Victor Noël (@victornoel) in #15363 (comment)
Examples
I had the case that a library came with a
dist/folder and almost all types were perfectly arranged in .d.ts files. But one file was making an import from../index.d.ts(which seems to be for development purposes, the lib main file isdist/index.d.ts) which in turn then importedsrc/ClassA.tsThe library author used a different tsconfig and didn't use strict type checking, but I do and that's why the type check fails for me, because now the typescript source files of the library author are type checked.
Checklist
My suggestion meets these guidelines (in case of a new option):