Open bensaufley opened 5 years ago
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
?
You're right, that wasn't the right phrasing (I was thinking of skipLibCheck: false
—excluded from enabled libCheck).
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
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 :)
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.
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?
We discussed this today and decided that its fate is linked to that of https://github.com/microsoft/TypeScript/issues/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'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?
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
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.
@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.
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-error
s due to typing issues in external packages.
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
Coming here from https://github.com/microsoft/TypeScript/issues/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:
skipLibCheck: false
takes ~3 minutesskipLibCheck: false
takes ~10 minutesskipLibCheck: true
takes ~3 minutesAs 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:
skipLibCheck: false
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.
That difference seems surprising. Do you have an active PR/branch with the above I could test? I was thinking it might be https://github.com/babel/babel/pull/16416 but that doesn't actually seem to be it.
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#.
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?