Disable type checking for node_modules entirely

Search Terms

skipLibCheck node_modules ignore library exclude

Suggestion

Either a new option or the existing option skipLibCheck should be able to disable type checking for node_modules.

Use Cases

A library author might have a faulty import or might only provide typescript files for his library and not transpiled code. As a user of this library I want to be able to disable type checking for a library (or all) because I trust this library has been tested enough in other ways.

Another issue where I found a library shipping ts files and causing errors for the user: https://github.com/microsoft/TypeScript/issues/15363

The response at the end is very relevant

I understand that libraries shouldn’t publish *.ts files, but sometimes, they just do, and we can’t control every other library easily. I think typescript should not try to apply this kind of setting (here noImplicitAny) to the node_modules simply because it is meant to be applied to the user code being compiled, not the external dependencies.

_Originally posted by @victornoel in https://github.com/microsoft/TypeScript/issues/15363#issuecomment-309459043_

Examples

I had the case that a library came with a dist/ folder and almost all types were perfectly arranged in .d.ts files. But one file was making an import from ../index.d.ts(which seems to be for development purposes, the lib main file is dist/index.d.ts) which in turn then imported src/ClassA.ts

The library author used a different tsconfig and didn’t use strict type checking, but I do and that’s why the type check fails for me, because now the typescript source files of the library author are type checked.

Checklist

My suggestion meets these guidelines (in case of a new option):

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• 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.

[aprilmintacpineda]

Can we please get a flag to suppress any error messages from files originating from node_modules? Doesn’t matter if there are 1 million errors if they are in node_modules, just ignore them, don’t display them, and exit with code 0. The only time when we should exit with code 1 is when there are errors anywhere else other than node_modules

skipLibCheck is NOT a solution, it’s going to disabled ALL declaration files checks, including YOURS!

An example of unwanted error:

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:38:5 - error TS2300: Duplicate identifier 'grey10'.

38     grey10: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:39:5 - error TS2300: Duplicate identifier 'grey20'.

39     grey20: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:40:5 - error TS2300: Duplicate identifier 'grey30'.

40     grey30: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:41:5 - error TS2300: Duplicate identifier 'grey40'.

41     grey40: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:42:5 - error TS2300: Duplicate identifier 'grey50'.

42     grey50: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:43:5 - error TS2300: Duplicate identifier 'grey60'.

43     grey60: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:44:5 - error TS2300: Duplicate identifier 'grey70'.

44     grey70: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:45:5 - error TS2300: Duplicate identifier 'grey80'.

45     grey80: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:46:5 - error TS2300: Duplicate identifier 'grey10'.

46     grey10: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:47:5 - error TS2300: Duplicate identifier 'grey20'.

47     grey20: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:48:5 - error TS2300: Duplicate identifier 'grey30'.

48     grey30: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:49:5 - error TS2300: Duplicate identifier 'grey40'.

49     grey40: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:50:5 - error TS2300: Duplicate identifier 'grey50'.

50     grey50: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:51:5 - error TS2300: Duplicate identifier 'grey60'.

51     grey60: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:52:5 - error TS2300: Duplicate identifier 'grey70'.

52     grey70: string;
       ~~~~~~

node_modules/react-native-ui-lib/typings/generatedTypes/colors.d.ts:53:5 - error TS2300: Duplicate identifier 'grey80'.

53     grey80: string;
       ~~~~~~

Okay, so? I don’t really mind that there are type errors on the libraries we use, I only mind that there are type errors on the codes that we wrote anywhere else other than node_modules.

I have 121 errors all of which are from node_modules.

Can someone explain what’s the reasoning why we would want to be blocked by errors coming from node_modules? I want to implement a tsc --noEmit on a github check so that every PR will be checked before we event want to review the changes. When the github check fails, we should not be able to merge the PR because the check ensures code quality.

[icywolfy]

We have been forced to disable strict: true on all our repos.
Third-party libraries ship only .ts files. The package.json has entry point as index.ts. After a year of requests and pressure, no progress has been made convincing other companies to make changes to what they publish.

The code compiles properly, and works at runtime. However, we wish to have strict: true enabled in our builds. However this is not possible. Required packages publish only raw .ts files, which do not meet strict: true, preventing automated enforcement of standards within code that we do have control over.

Being unable to enable any strict typing, solely because we consume third-party packages that don’t meet the same strictness, and of which we have no leverage for change:

• use of any,
• function type mismatches (../../node_modules/@***/***/src/sdk/*****Api.ts:302:9 - error TS2322: Type '(value?: void | PromiseLike<void>) => void' is not assignable to type '(value?: unknown) => void'
• ../../node_modules/@***/***/src/sdk/*****Api.ts:21:16 - error TS2532: Object is possibly 'undefined'

We have a manual process that is sometimes applied:

• check out a PR,
• manually perform a tsc --noEmit --project tsconfig-strict.json,
• filter out hundreds of errors from node_modules/ .ts file only libraries
• find errors in code we own Which is error prone, and allows typing problems in our code to slip through.

I had suggested something similar to this : https://github.com/microsoft/TypeScript/issues/44205. But it was rejected as “configuration issue”.