A TypeScript project's `tsc --noEmit` has crept from twenty seconds to four minutes with no new dependencies. How do you find which types are responsible?

## Measure first — the culprit is rarely where you think The failure mode in this situation is a senior engineer rewriting the type helper they personally dislike, shipping it, and finding the build is still four minutes. Type-check cost is unintuitive because it is driven by instantiation counts and comparison work, which do not correlate with how clever a type *looks*. So the workflow is measure, localise, fix, re-measure. ## Step 1: `--extendedDiagnostics` ```bash npx tsc --noEmit --extendedDiagnostics ``` This prints a summary that includes file, line and node counts, the number of **Types** and **Instantiations** the checker created, memory used, and a breakdown of time by phase — I/O read, parse, bind, check, emit, total. Read it as a triage table: - **Check time dominates, instantiations enormous, file count flat** — this is type-level work. Continue to tracing. - **Parse and I/O time dominate, file count large** — this is project size and file inclusion, not clever types; look at what is being pulled into the program. - **Memory is very high** — often big unions or deep recursive instantiation. Run it before and after a change so you have a number to compare, and run it a couple of times: a cold first run on a large repo is not comparable with a warm one. ## Step 2: `--generateTrace` plus the analyzer ```bash npx tsc --noEmit --generateTrace traceDir npx @typescript/analyze-trace traceDir ``` `--generateTrace` writes a trace of the compiler's work into the given directory. The `@typescript/analyze-trace` package — published by the TypeScript team for exactly this job — reads that output and prints the hottest spots attributed to files and source positions, so the answer is "this helper at this line took 40 seconds" rather than a hunch. The raw trace is also a standard trace format that a trace viewer can open, but the analyzer is the fast path. ## Step 3: rule out the boring explanations Before blaming your own types, eliminate the causes that have nothing to do with them: - **Dependency declaration files.** `skipLibCheck` skips type checking of `.d.ts` files. Toggling it tells you how much of the time was spent checking dependencies rather than your source. (Whether to leave it on is a separate policy question.) - **What is in the program at all.** If far more files are being included than you expected, the cost is inclusion, not cleverness. - **Incremental state.** With `--incremental`, or with project references, a warm build and a cold build are wildly different numbers; make sure you are comparing like with like. - **The machine.** A CI runner change or a memory-constrained container can produce the same symptom with no code change at all. ## Step 4: confirm by bisecting Tracing points at a location; it does not prove causation. Confirm the way you would confirm any performance hypothesis: remove or neuter the suspect — replace the helper's body with a plain explicit type, or `any` it temporarily — and re-run `--extendedDiagnostics`. If the number does not move, you had the wrong suspect. Git history is the other bisection axis: the build crept up over a quarter, so `git bisect` against a timed type-check will find the commit even when the trace is ambiguous. ## Step 5: fix, in rough order of leverage 1. **Annotate return types on exported functions.** Cheapest and usually the biggest single win, because it stops the checker inferring and re-expanding a large anonymous type at every call site. 2. **Split the helper into named intermediate aliases**, which improves reuse of cached relation results and, as a bonus, makes the error messages legible. 3. **Constrain type parameters** so the checker explores less. 4. **Reduce union size** — a cross-product that produced tens of thousands of members is a common single cause. 5. **Delete the cleverness.** If the helper's guarantee could be written as a plain interface, that is very often the correct fix, not a defeat. If the guarantee is really about external data, it belongs in a runtime validator anyway. ## Don't forget the editor The number your teammates feel is not `tsc`; it is the responsiveness of the TypeScript server behind their editor, which re-answers completion and hover queries as they type. A change that halves CI time but leaves one file's completions at two seconds has not solved the complaint people actually have. Verify the fix by opening the worst file and typing in it, and if the editor is the main symptom, capture the TypeScript server's own log from your editor to see which requests are slow. ## What the interviewer is listening for A process, in order, with real tool names: measure with `--extendedDiagnostics`, localise with `--generateTrace` and the analyzer, eliminate the boring causes, bisect to confirm, then fix and re-measure. Candidates who jump straight to "I'd rewrite the conditional types" are describing a guess; candidates who mention only "turn on `skipLibCheck`" have one trick rather than a method.