-
Notifications
You must be signed in to change notification settings - Fork 12.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: allow exclusion of node_modules when skipLibCheck is false #30511
Comments
It sounds like you're asking for the opposite - a mode for |
You're right, that wasn't the right phrasing (I was thinking of |
FWIW I think this ongoing issue is my biggest use case for this flag: Styled-Components automatically includes React-Native types, which duplicate Node types, so if you use Styled-Components and Node, you must |
Another use-case for this feature comes from nexus. Nexus has a novel "typegen" feature wherein based on user code a TS types file is generated and via interface-merging is able to imbue static guarantees on otherwise dynamic app code. We are currently working on making the default disk location for this typegen be Now, the motivation, for us, for this TS issue, is that nexus typegen would become weaker in the face of Hope that makes sense :) |
I completely agree with the author. I am not sure if it would make sense or whether this has any negative effect, but the only way I could make sure my declaration files didn't have any errors, was to rename all I faced many situations where I did have errors on my I might be missing something though. |
My use case for this is also related to the It does not harm my code, so I would like to ignore all those errors by setting Any updates on this? |
We discussed this today and decided that its fate is linked to that of #39231. Currently, we have a fairly coherent posture that |
I'd propose a new setting
which says that any Thoughts? |
What about this kind of types collection? https://github.com/sindresorhus/type-fest |
Those files are not exempt from the behavior I described. If you import from type-fest with the compiler option |
@RyanCavanaugh I don't have a lot of examples, but here are some:
But I think the battle to force people to generate typing for package is to be done here: https://twitter.com/colinhacks/status/1635427374530691074 Personally I love the direction that Bun and Deno enables. Having TS runtime give back to publishing small libraries the simplicity it was at the beginning with the power of TS for both authors and users. |
Then disable it on `npm run lint`. lib-check cannot exclude `node_modules`: * microsoft/TypeScript#30511
I think this is a generally reasonable posture, but if you have to do type augmentation, that needs to be done by hand and is 100% an exception to the whole "[.d.ts] are not inputs to be hand-authored" I don't have any particular interest running typechecking on .d.ts files that are emitted by |
I have also wished to have more nuance around I only wish to |
Coming here from #43140. I am trying to enable project references in Babel to speed up incremental type checking, and this is being a partial blocker. We cannot use
As a workaround, we are probably going to use
For this use case, {
"compilerOptions": {
"skipLibCheck": [
"./packages/*/lib/**/*.d.ts",
"./codemods/*/lib/**/*.d.ts",
"./eslint/*/lib/**/*.d.ts",
]
},
} I'd be happy to open a PR for it. |
That difference seems surprising. Do you have an active PR/branch with the above I could test? I was thinking it might be babel/babel#16416 but that doesn't actually seem to be it. |
Search Terms
skipLibCheck node_modules
,skipLibCheck
All I've found is this lonely SO post. As that user notes, there are a lot of posts around Angular and excluding node_modules from typechecking on one dimension or another, but they all end up suggesting turning on
skipLibCheck
.Suggestion
Allow the exclusion of files in node_modules (regardless of their inclusion in the Project) from lib checking when
skipLibCheck
is set tofalse
.Use Cases
I want to be able to typecheck my own
.d.ts
files without being responsible for all of the types my dependencies import. My local configuration isstrict
and it may be that the types provided in my packages were not intendedstrict
ly, or other configurations in my local JSON run up against the way other packages have written theirs.I am assuming the counterargument is that it's all-or-nothing, but then why do
.ts
files that rely on.d.ts
files typecheck fine when my.d.ts
files are not typechecked? Can't that behavior be applied to definitions in node_modules?Examples
Not sure how to show an example here. I would like to be able to run
tsc --noEmit
on my codebase and get errors for my own definitions files without having a bunch of noise from unfixable errors innode_modules/@types
etc.Checklist
My suggestion meets these guidelines:
If implemented as some additional flag?
I think so?
The text was updated successfully, but these errors were encountered: