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.

[kodra-dev]

I fully agree with this. Another (admitted niche) user case: I'm using https://github.com/Tencent/puerts for my game It's a Javascript/Typescript runtime for Unity. To access C# runtime from Typescript, it generated *.d.ts files from C# classes. However, in most case you'd like to draw a clear line between C# codebase and Typescript codebase, and therefore only want to generate *.d.ts for a few classes that "glue" between C# and TS.

Obviously, it would cause some unresolvable symbols in those generated *.d.ts, and it's totally fine. But I'd still like to check other *.d.ts files that are NOT generated from C#.

[robert-melonn]

Hello @RyanCavanaugh @andrewbranch , is there any intention to review these types of cases? There are a lot of issues referencing these behaviours but nothing concrete is achieved. There are a lot of use cases for having this property skipping folder patterns, something like skipLibCheck: ["node_modules/", "./src/undesired_handwritten.d.ts"].
Even working with project references is a nightmare when it comes to monorepos (widely used today). I feel that no one has paid attention to specific behaviors that typescript has (or ignores them) otherwise the community would have stopped using typescript a long time ago.

There are some big gaps in the explanations of how tsconfig files actually work. I absolutely believe that more than 90% of the community believes that an exclude: ["node_modules/"] is saying that typescript will not check for files in that folder so they are ignored even though the documentation explains it. Configuration properties names must convey their intent, which tsconfig files do not.

There are problems when dealing with typescript projects from different environments (or intentions), such as whether I want to verify source, tests, storybook, e2e, build or node files. I'm almost sure people think that adding a tsconfig.node.json
will actually check the types of your included files (unless you specify that file in the tsc command). We don't have a clear way to check everything at once avoiding type collisions, configurations, without using the annoying, unpredictable, slow and almost undocumented project references. On many occasions I have seen proposals and suggestions from the community, such as an override per environment in a single tsconfig.json file, but I feel that everything the community suggests is still being ignored, even if it solves real problems .

We must do something

[KevinGhadyani-Okta]

My 2 cents

I probably riding the bandwagon here, but I want to add my thoughts as someone who runs into this issue in every single TS project and has yet to find a suitable solution. I've always enabled skipLibCheck, but the fact that it doesn't check types in my local index.d.ts files is something I know but most don't. I remember when I first found that out by mistake.

Type checking someone else's files

It makes no sense to me that I'd wanna check someone else's types when it's their job to check their own types before releasing a version of their library. I have to have trust that the library I'm importing is both tested and functional; I can't make an assumption that they did everything wrong because fixing it isn't my job, and not something I can easily control.

I'm sure there's a great argument for why you need to check someone else's types in your library similar to the argument for why it's important to re-bundle someone else's production library code because they might've used a different browserslist config.

As unintuitive as it may seem, skipLibCheck: true should probably be the default. Like @robert-melonn suggested, I assumed that excluding a directory also excludes it from type checking. Wasting hours on an issue caused by an unintuitive config file setting isn't a great user experience. TypeScript will have more new users than old users over time, and they're all gonna run into this same issue as I did. It's a 100% given. I don't know anyone who hasn't run into this issue.

How I got here

The entire reason I found this thread is because I'm trying to figure out a way to have local index.d.ts files for when I need to create types for a 3rd party library, but that file isn't typechecked, and any attempt at doing types.ts doesn't work the same when using "type": "module". If this is supposed to work, I'd argue the documentation is lacking, and that all stems from the fact that it's unintuitive.

[thorn0]

@KevinGhadyani-Okta Use declare global { ... } instead of the .d.ts extension. Same thing but not affected by skipLibCheck.

[robert-melonn]

@thorn0 declare global is just for modules that use window object. It shouldnt be used arbitrarily