Feature Request: allow exclusion of node_modules when skipLibCheck is false

[bensaufley]

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 to false.

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 is strict and it may be that the types provided in my packages were not intended strictly, 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 in node_modules/@types etc.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
  If implemented as some additional flag?
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.
  I think so?

[RyanCavanaugh]

It sounds like you're asking for the opposite - a mode for skipLibCheck that says only skip checking of .d.ts files from node_modules?

[bensaufley]

You're right, that wasn't the right phrasing (I was thinking of skipLibCheck: false—excluded from enabled libCheck).

[bensaufley]

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 skipLibCheck because of a long-standing problem that you have no power to fix

[jasonkuhrt]

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 node_modules/@types/whatever/index.d.ts. This allows nexus to provide the typegen DX without any config demands upon the user.

Now, the motivation, for us, for this TS issue, is that nexus typegen would become weaker in the face of skipLibCheck. Advanced users can configure typegen output, but their getting it wrong while skipLibCheck: true would make it silently fail. This TS feature would help maintain our users' confidence in nexus typegen even in situations where they need to skipLibCheck for just one or two libs in their project.

Hope that makes sense :)

[zanona]

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 .d.ts to .ts, while keeping skipLibCheck=true.

I faced many situations where I did have errors on my .d.ts files to only figure it out once those were then checked by tsc after being renamed.

I might be missing something though.

[cbdeveloper]

My use case for this is also related to the styled-components and @types/react-native issue. I'm getting 40 errors.

It does not harm my code, so I would like to ignore all those errors by setting --skipLibChecks: true, while still checking and getting errors for my own .d.ts files inside my src folder.

Any updates on this?

[andrewbranch]

We discussed this today and decided that its fate is linked to that of #39231. Currently, we have a fairly coherent posture that .d.ts files are either outputs or they describe the shape of colocated JS (as in libraries), but they’re not inputs to be hand-authored. There are reasons to reconsider that stance, but we would do so altogether, and such a change in perspective would likely address this issue and #39231, but it’s not something we’re actively exploring right now.

[RyanCavanaugh]

I'd propose a new setting

`"skipLibCheck": "external"

which says that any .d.ts file in your files or include pattern is checked, but any .d.ts file that gets into your program via other means is not (e.g. node_modules imports, output .d.ts files from upstream project references)

Thoughts?

[skarab42]

We discussed this today and decided that its fate is linked to that of #39231. Currently, we have a fairly coherent posture that .d.ts files are either outputs or they describe the shape of colocated JS (as in libraries), but they’re not inputs to be hand-authored. There are reasons to reconsider that stance, but we would do so altogether, and such a change in perspective would likely address this issue and #39231, but it’s not something we’re actively exploring right now.

What about this kind of types collection? https://github.com/sindresorhus/type-fest

[andrewbranch]

Those files are not exempt from the behavior I described. If you import from type-fest with the compiler option --importsNotUsedAsValues preserve, the output will crash despite not hearing an error from us. When type-fest exposes module .d.ts files that export types, it implies that there are corresponding .js files that export nothing, which is very different from there not being .js files. To correctly reason about a library like type-fest, we would need a completely new concept of a type-only module, which is known to have no runtime counterpart. Alternatively, collections of utility types could choose to declare a global namespace rather than modules, so users would just use tf.EmptyObject instead of importing EmptyObject, for example. But I understand why that feels less desirable. Fortunately, the majority of users have no reason to set --importsNotUsedAsValues preserve, and many folks are writing import type for these imports anyway, so in practice, I don’t think anyone is getting hit by this. But hopefully it explains that yes, even type-fest technically implies the existence of a set of empty .js modules.

[ArnaudBarre]

@RyanCavanaugh I don't have a lot of examples, but here are some:

• https://github.com/huggingface/huggingface.js/blob/b7934a51c87ab407dca9b28a2c0d6520334a153d/packages/hub/package.json#L11
• https://github.com/oedotme/generouted/blob/bda257eb8f540060003fc490415450ec5b272a3a/packages/generouted/package.json#L35

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.

[FFdhorkin]

We discussed this today and decided that its fate is linked to that of #39231. Currently, we have a fairly coherent posture that .d.ts files are either outputs or they describe the shape of colocated JS (as in libraries), but they’re not inputs to be hand-authored. There are reasons to reconsider that stance, but we would do so altogether, and such a change in perspective would likely address this issue and #39231, but it’s not something we’re actively exploring right now.

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 tsc, but I 100% want type checking in my src/type-augments.d.ts file, which I use to prevent excessive // @ts-expect-errors due to typing issues in external packages.

[robrez]

I have also wished to have more nuance around skipLibCheck... a frequent issue I've encountered is a breakage in typedefs from a library because, for example, the library (or one of its transitive dependencies') author changed typescript versions and the vended types are no longer compatible with my project's (lower) typescript version.

I only wish to skipLibCheck for that particular portion of my dependency graph - that upsets the compiler

[nicolo-ribaudo]

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 skipLibCheck, because we have multiple manually-written .d.ts files that need to be checked. When migrating to project references, type checking gets more than 3x slower:

• "monolithic project" with skipLibCheck: false takes ~3 minutes
• project references with skipLibCheck: false takes ~10 minutes
• project references with skipLibCheck: true takes ~3 minutes

As a workaround, we are probably going to use skipLibCheck: true in most projects expect for the ones that contain manually-written .d.ts files, but:

• it still incurs in a ~20 seconds performance penalty for each project that has skipLibCheck: false
• it's easy to accidentally forget to set skipLibCheck: false in a project when adding a .d.ts file.

For this use case, skipLibCheck should accept a pattern so that I can exclude .d.ts files generated by tsc (while still type-checking manually-written .d.ts and .d.ts from my dependencies):

{
  "compilerOptions": {
    "skipLibCheck": [
      "./packages/*/lib/**/*.d.ts",
      "./codemods/*/lib/**/*.d.ts",
      "./eslint/*/lib/**/*.d.ts",
    ]
  },
}

I'd be happy to open a PR for it.

[jakebailey]

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.