Your CI step that runs tsc --noEmit has grown to several minutes on a mid-sized TypeScript repo. Which compiler flags and measurements would you use to find where the time is actually going?

## Why this problem exists at all In a split pipeline the bundler is fast and the checker is the slow half, so the type-check job becomes the long pole in CI. The temptation is to make it faster by making it weaker — dropping it to non-blocking, or narrowing what it checks. The professional move is to find out where the time goes first, because in practice a large fraction of slow check jobs are slow for a fixable and slightly embarrassing reason. ## Step one: --extendedDiagnostics ```bash tsc --noEmit --extendedDiagnostics ``` This prints a summary that includes the number of files, lines, nodes, identifiers and symbols, the number of **types** and **instantiations** created, memory used, and a time breakdown across parse, bind, check and emit (plus a total). Read it as a triage tool: - **Files far higher than expected** → the program is too big. You are checking things you did not mean to check. - **Instantiations in the millions with check time dominating** → the program is the right size but the type-level work is expensive: deeply recursive conditional or mapped types, enormous unions, heavily overloaded generic helpers. - **Large parse time relative to check** → sheer volume of source, often the same "too many files" story. ## Step two, branch A: what is even in this program? `--listFiles` prints every file included. `--explainFiles` goes further and prints, for each file, the reason it was included — an entry point, an import from a specific file, a `types` package reference, a root of the `include` glob. That "why" column is what turns a guess into a diagnosis. Classic findings: an `include` glob that reaches build output or fixtures, an unnecessary `@types` package pulled in globally, or a directory of generated code nobody meant to check. `--traceResolution` is the more granular cousin, printing how each module specifier was resolved — useful when the surprise is *which* copy of a package got loaded. Also check `skipLibCheck`. Without it, the compiler checks the declaration files of your dependencies against each other; with a large dependency tree that can be a serious share of the total. It is a common and generally accepted setting for application code precisely because of this cost. ## Step two, branch B: what type is so expensive? ```bash tsc --noEmit --generateTrace traceDir npx @typescript/analyze-trace traceDir ``` `--generateTrace` writes trace output into the given directory; `@typescript/analyze-trace` (published by the TypeScript team) reads it and reports hot spots — the files that took longest to check and the specific type instantiations responsible. This is how you find the one utility type that a hundred call sites instantiate recursively, or the single enormous union that everything is compared against. The fixes that follow are type-level, not build-level: give an expensive inferred type an explicit annotation so the checker stops recomputing it, cap a recursive type's depth, replace a giant conditional chain with a lookup, or split a monstrous union. ## What good practice looks like Measure, form a hypothesis, change one thing, measure again with the same flag. Keep the numbers — a `--extendedDiagnostics` line in CI logs is a cheap regression detector, because the instantiation count usually jumps the day someone lands a clever type. And hold the line on the gate itself. Making the check non-blocking, or excluding the tests from it, converts a latency problem into a correctness problem: the job gets faster and stops telling you anything. If latency is genuinely unacceptable, run the check in parallel with the build job rather than shrinking what it covers. ## The judgment being tested An interviewer asking this wants to see that you reach for measurement rather than folklore, that you know the compiler ships its own instrumentation, and that you can distinguish "the program is too big" from "the types are too expensive" — because those two diagnoses have completely different fixes and confusing them wastes days.