Usage of the TypeScript compiler argument 'skipLibCheck'

Question

I've been researching around for a further explanation into the skipLibCheck TypeScript compiler argument to determine the safety of having this set to true. The most in-depth explanation I found is the following:

New --skipLibCheck TypeScript 2.0 adds a new --skipLibCheck compiler option that causes type checking of declaration files (files with extension .d.ts) to be skipped. When a program includes large declaration files, the compiler spends a lot of time type checking declarations that are already known to not contain errors, and compile times may be significantly shortened by skipping declaration file type checks.

Since declarations in one file can affect type checking in other files, some errors may not be detected when --skipLibCheck is specified. For example, if a non-declaration file augments a type declared in a declaration file, errors may result that are only reported when the declaration file is checked. However, in practice such situations are rare.

I understand that you obviously get a performance benefit from the compiler not having to type check files which are considered not to contain errors but I've seen this flag being used to get around errors being emitted from the compiler in relation to the declaration files having problems.

Surely using this flag to get around this decreases the integrity of the typing of your application?

Vestige

Yes in the sense that depending on what the errors were, the compiler may recover from them in a way that causes problems elsewhere in the code to go unnoticed (for example, by replacing an erroneous type with any), hence suppressing type errors (whether by --skipLibCheck, //@ts-ignore, or any other means) is a risky practice. If you had a more specific question, please clarify it. – Cryptogam

I happened to work on a project of a customer where they had some version clashes of different dependencies which weren't fixed by the resolutions option in the package.json. Basically differently typed versions of some React typings which caused the compiler to bail and exit with an error. Enabling this option helped to "ignore those mismatches of typings" until I fixed them via proper resolutions. – Flavourful

Answer 1

To paraphrase the question tersely:

Surely [enabling skipLibCheck] decreases the integrity of the typing of your application?

I would agree that yes, it does. However, if the alternative is an application that does not compile, then it becomes a handy flag.

While Typescript itself is fairly mature, the typescript community is still relatively young. There are type definitions available for tons of libraries, and even some native typescript libraries, but they can be incompatible with one another for a variety of reasons.

You may import a library whose typing is built with a less-strict tsconfig than you would like--which your compiler could complain about when you try to use it.

You could find two libraries define the same types, but incompatibly. I've imported some libraries that supplied their own typings for a Polyfill of Buffer, and my whole application would fail to compile because of their incompatibility.

Enabling --skipLibCheck can help work around these issues. Turning it on will prevent Typescript from type-checking the entire imported libraries. Instead, Typescript will only type-check the code you use against these types. This means that as long as you aren't using the incompatible parts of imported libraries, they'll compile just fine.

tl;dr, Yes, --skipLibCheck degrades type checking, and ideally we wouldn't use it. But not every library provides perfect types yet, so skipping it can be nice.

Mattheus

Given that --skipLibCheck speeds things up, it might make sense to use it for your everyday, dozens-of-times-a-day development compiles, but then occasionally use without (especially when initially incorporating new libraries) to assure yourself that everything passes the full type checking in the event that something gets missed by the abbreviated check. You can have the benefit of both that way. – Freesia

I can also come in handy when using webworkers together with some libraries such as TFjs. See #64606767 – Permissible

"You may import a library whose typing is built with a less-strict tsconfig than you would like" --- ideally it seems that one typescript mode could give a warning if the types intersected, and only error if they had no intersection. " You could find two libraries define the same types, but incompatibly." --- ideally typescript should be able to recognize the equivalency and allow it. – Vicentevicepresident

Works like a charm for the compiling error error TS2717: Subsequent property declarations must have the same type. – Lao

I'm here because I'm getting a circular reference typescript error in a React module, in a freshly created React project. type alias 'ReactFragment' circularly references itself. Didn't expect to be this far into the weeds this quickly. – Sailer

Answer 2

Although some libraries (hello, Tensorflow.js!) officially recommend to set skipLibCheck to true, there's one more hidden drawback. It won't only tell compiler to skip d.ts type checking in code that you can not control (i.e. node_modules), but instead it skips all d.ts files.

So if you are using d.ts as declaration files, there's currently no way to type check them separately (open issue – https://github.com/microsoft/TypeScript/issues/30511). I ended up converting my <name>.d.ts to <name>.types.ts, which was not optimal in many ways, but at least provided type safety inside my own code while keeping separation of interfaces and implementations.

Contrivance