Broken (unrelated) ambient types in the user's node_modules can cause --emit-tsd builds to fail

[jedrichards]

The tsc invocation here seems sensitive to unrelated broken types present in the users node_modules/@types folder.

I believe TypeScript checks types in node_modules/@types, and it's not uncommon for these to be broken in some way (duplicate identifiers when multiple versions of the same package are present in a monorepo, 3rd party type incompatibilities and so on).

The issue is solved by passing the --skipLibCheck flag to tsc. Or alternatively, perhaps invoking tsc in some temporary cwd that is not the user's project, where we're not going to trigger random errors from npm dependencies.

[brendandahl]

With --skipLibCheck are there any other issues that can come up from running tsc in the CWD?

[jedrichards]

@brendandahl From what I understand, --skipLibCheck is something you might want to turn on when you want to validate that everything is working also with respect to .d.ts types that might be coming in from dependencies (from node_modules/@types/...) that you want to be compatible with - for example, prior to publishing a TypeScript libray to npm or something.

So I think, it's sensible to toggle it off when we're just typechecking our own code, especially if that code is self-contained (i.e. it doesn't rely on any 3rd party ambient types itself).

With --skipLibCheck any broken types from node_modules that are actually referenced, are typed as any, but non-broken ones are still properly typed. But that may be a moot point anyway, since in this case, I do not think js_doc_file uses any 3rd party types?

It seems common practice to use the flag:

• When you call tsc --init, to scaffold a new TypeScript project, the flag is set for you
  • https://github.com/microsoft/TypeScript/pull/37808
• There is a nice ticket in the Vite repo, where they list out some related tickets and pros/cons
  • https://github.com/vuejs/vue-cli/pull/5688