`skipLibCheck: true` is ignored when package's `types` field points to a `.ts` file (not a `.d.ts` declaration file)

[trusktr]

TypeScript Version: 3.9.7

Search Terms:

skipLibCheck is ignored
skipLibCheck not working

Code

N/A

Expected behavior:

TypeScript should ignore type errors in node_modules (or skip reporting them? I'm not sure exactly what skipLibCheck does).

Actual behavior:

When skipLibCheck is set to true, TS will still have type errors in packages in node_modules. It seems that this is the case if a package's types field in the package's tsconfig.json file points to a .ts file instead of a .d.ts file.

For example, in my project that consumes the lume package, there are type errors like these:

node_modules/lume/src/html/WithUpdate.ts:132:13 - error TS2784: 'get' and 'set' accessors cannot declare 'this' parameters.

132     get props(this: any): any {
                  ~~~~~~~~~

node_modules/lume/src/core/Utility.ts:5:10 - error TS7030: Not all code paths return a value.

5 function applyCSSLabel(value: any, label: any) {
           ~~~~~~~~~~~~~

As you can see the path in the errors are in node_modules. The lume package's types field points to its src/index.ts file, and hence all the types in that package are based on .ts files instead of .d.ts files.

Playground Link:

N/A

---

Maybe I misunderstand what skipLibCheck does. What should it do exactly?

[RyanCavanaugh]

skipLibCheck causes the "check each top-level statement or declaration" step to not occur for .d.ts files.

It has no other effect. It does nothing in .ts files, and is not a guarantee that you won't encounter errors in .d.ts files whose declarations get examined as a part of their resolution.

[trusktr]

I think one would intuitively expect no errors from inside node_modules (unless it is critical, like invalid syntax?) when skipLibCheck is true, because ultimately the dependency code is plain JavaScript (or will end up as plain JavaScript).

For example, the Webpack build in the consumer app works fine, it pulls in the non-.ts files from dist/, and the app works fine.

The types in the lume package work just fine when that repo is cloned and build with tsc. The errors I see are in another project that just installed lume and presumably uses a different version of tsc. Intuition here expects the code to be fine.

How do we assert to tsc that everything is fine and to strictly ignore those type errors in node_modules?

[RyanCavanaugh]

There isn't a setting that would cause TypeScript to not issue an error in a .ts file

[trusktr]

This circles back to (some issues in) #35822, because we can not consume mixin classes from a package unless the package's types field points to .ts files (because the package author can not output declaration files if they use mixin classes).

[trusktr]

Without types pointing to .ts files, making mixins can go like follows.

From #17744 (comment) (@justinfagnani):

The workarounds we've had to do to satisfy the compiler are pretty onerous. We've created a fake class outside of the mixin and cast the mixin function to return an intersection of the argument and that class. Static require another fake class. Then we need to get our build system to remove the fake class. I'm not sure this approach solved every problem yet.

[DanielRosenwasser]

We are interested in making .d.ts file generation less of a hassle, but patching skipLibCheck for the use-case of shipping .ts files to get around the issues described is not the direction we want to take.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[trusktr]

@DanielRosenwasser Is it possible to make TypeScript skip type-checking source files of libraries (i.e. when their package.json types field points to source instead of declaration files)?

This would make shipping neat features possible, that are otherwise currently not allowed when declaration output is turned on.

As an example, all the issues listed in #35822 would be solvable by simply recommending people in those cases to point their types fields to their source entrypoints.

The alternatives are to wait an unknown number of years for a solution, or to abandon the cool features. Adding such a solution would be a very simple unblocker for those nice use cases.

Of course, if declaration output could be fixed, that'd be preferable, but the pace at which that is happening is very slow, and the alternative suggested solution seems to be a lot easier to unblock many people from using cool patterns.

[DanielRosenwasser]

If the community starts shipping full source in place of .d.ts files, my expectation is that users would start running into scalability concerns in building (and this is actually much of the motivation for project references). It would also potentially exacerbate issues where .d.ts emit would otherwise be stable when adopting new non-declaration ECMAScript features.

[borekb]

This issue, together with #38538, is what we're seeing as well.

The core seems to be that that TypeScript checks imported .ts files regardless of whether they are source files or external dependencies, and options like include, exclude or skipLibCheck don't have any effect on this (rightfully so but that doesn't make the issue go away 😄).

We think that TypeScript just crawls imports inside files that match include / exclude and that it then runs a typecheck on everything it finds:

• .ts files are checked unconditionally
• .d.ts files are checked if not disabled via skipLibCheck

The first point is a problem – we don't want to see errors from node_modules or generally from .ts files that are not source files of the current project.

I acknowledge that skipLibCheck might not be possible to amend (though intuitively, node_modules/some-plain-ts-library is a library) but there should be some way to prevent it. There is currently no workaround as far as I know.

---

Some context: besides the use case reported by the OP ("types" pointing to .ts), there's another one.

Modern frameworks like Next.js, Gatsby, CRA and others process TypeScript "natively" so it's actually better not to transpile .ts and leave this job on webpack / Babel / esbuild / whatever the transpilation pipeline that framework uses. This leads to a new world where .js + .d.ts files don't exist on the disk – for example, in our Next.js project, we never run full transpilation, that's up to the next dev / next build to produce some .js bundles.

We're using TypeScript as a "linter" only, i.e., tsc --noEmit.

[RyanCavanaugh]

The core seems to be that that TypeScript checks imported .ts files regardless of whether they are source files or external dependencies

The first point is a problem – we don't want to see errors from node_modules or generally from .ts files that are not source files of the current project.

This is indistinguishable from an intentional configuration. We'd need some more intentional way for you to specify what's "yours" and "not yours"