Typescript ignore errors in particular file via config

Question

Is it possible to ignore typescript errors in particular file via tsconfig.json? I know there is exclude property as described on their website, but this is not what I am looking for. As stated:

If a file B.ts is referenced by another file A.ts, then B.ts cannot be excluded unless the referencing file A.ts is also specified in the "exclude" list.

It is quite logical that when you use a certain npm package, it will be always checked by typescript. Even if you try hard to exclude entire node_modules or just particular one. You will be unsuccessful. So if there are typescript errors in certain node modules file (because of some reason, outdated types, versions mismatch, ...), then you are stuck.

All I am looking for is an option to ignore typescript errors in particular library file which I can not edit. Something like // @ts-nocheck, but on tsconfig.json level:

{
  "nocheck": [
    "node_modules/redux-thunk/index.d.ts"
  ]
}

The skipLibCheck compiler option is not a solution. I would still like to keep checking for other libraries.

Answer 1

TL;DR you cannot:

You can exclude a file from compilation (using a glob pattern) but as soon as you import a that file it will of course be included and part of your compilation.

TS will therefore check this file for errors. As the errors belong to the file and not to the import, there is no way to tell TS, import TS but drop the errors.

You therefore need to drop the typing. One possible workaround is to import the compiled js file directly which will drop the typing definition (and therefore possibly related "bugs").

Recent version of TS should normally let you import js files using the full explicit file name. Another hack could also be to import your dependency using require instead of import.

Last but not least, here are possible solutions:

• Perhaps the module you import has .ts files (while npm package should not include .ts files, only .d.ts), and perhaps you are importing one of those .ts file, you definitely should not.
• Your module is not bundled with it's typing, and you are importing the wrong TS definition version @types/packageName
• Your TS version is not up-to-date, or your module targets another TS
• In the worst case, you can still create a local version of the faulty npm module, fix it locally and use that one