Incremental compile can spend time type checking files with @ts-nocheck

[wnayes]

🔎 Search Terms

incremental, nocheck, @ts-nocheck, tsbuildinfo

🕗 Version & Regression Information

• This is the behavior in every version I tried (just latest 5.3.3 but I doubt it is new).

⏯ Playground Link

No response

💻 Code

The TypeScript compiler, during a subsequent --incremental compile, can end up doing semantic analysis of source files that are marked with @ts-nocheck. This is unexpected and different from a non-incremental compile.

I have not observed error diagnostics from the nocheck file actually get printed out from a compile, however the behavior can be quite noticeable performance-wise if a significant amount of code has @ts-nocheck and undergoes incremental compile.

Specifically, checkSourceFileWorker(node) processing can occur during incremental compiles for a source file that had @ts-nocheck (or technically, checkJsDirective.enabled == false). It seems this is unique to incremental compiles. It looks to me like a nocheck file can end up being iterated through via getNextAffectedFile, and when processing occurs on it, there is no checkJsDirective.enabled check. Only getBindAndCheckDiagnosticsForFileNoCache checks checkJsDirective.enabled, which doesn't appear to be a code path used for incremental checking.

It looks like ts.skipTypeChecking is checked in more places than checkJsDirective.enabled. I happened to confirm that the extra type checking work is avoided if ts.skipTypeChecking were to be edited to include such a check, so potentially that is relevant to a possible fix.

---

I don't think I can create a Playground link for this, because the issue to observe is basically "extra processing only during incremental compile."

I created this repo with a small project and some example traces that demonstrate the issue:
https://github.com/wnayes/incremental-no-check

The gist of it is that the large.ts file, marked with @ts-nocheck, can end up having CPU time spent type checking it during incremental compiles. There are instructions to reproduce the issue, however the "proof" is basically this line in some traces that I committed:

https://github.com/wnayes/incremental-no-check/blob/main/traces-2/trace.json#L318

There (as well as on many following lines) we can see semantic analysis being done on large.ts, yet the workflow never involves removing @ts-nocheck.

🙁 Actual behavior

Incremental compiles can spend CPU time doing semantic analysis on @ts-nocheck files, which seems wasteful.

🙂 Expected behavior

Incremental compiles shouldn't do semantic analysis on @ts-nocheck files.

Additional information about the issue

No response

[sheetalkamat]

This should be fixed by #58592