perf: build a solution on the programs of the build before it

[alexander-akait]

Summary

A rebuild in build mode made every project's program from nothing. tsc -b reads what it can back from .tsbuildinfo, but the sources are parsed and the project checked over again — so the one thing the non-build path already does, keeping its program between rebuilds (#331), the solution path did not.

The solution builder's host takes a createProgram of its own, which is the only hook it exposes. Ours keeps the parsed source files and hands each project the program the last build left it.

Measured, and the alternative was measured too. Over a generated two-project, 302-file solution, one file edited between passes, medians of 10 rebuilds over three interleaved runs:

	first build	rebuild	RSS
today	1243 ms	468 ms	412 MB
this	1239 ms	149 ms	267 MB

createSolutionBuilderWithWatch — the obvious candidate, and what fork-ts-checker-webpack-plugin uses — was tried first and rejected on the numbers: with its watchers replaced by ours (webpack owns the watching here, per #334) its rebuilds were no faster than today's ~500 ms, it held 503 MB, and after the second pass invalidateProject stopped rebuilding at all, so it answered from stale programs. It only works with TypeScript's own file watchers, which would duplicate webpack's.

One thing measuring turned up that this PR does not fix. build mode inherits tsc -b's timestamp up-to-date check, so an edit whose mtime does not exceed the previous build's outputs — an edit made while a build is running — is silently skipped and reported as clean until something else changes. It reproduces on main (status=UpToDate, input mtime equal to .tsbuildinfo's) and is unrelated to this change; worth its own issue.

What kind of change does this PR introduce?

perf

Did you add tests for your changes?

Yes — test/typescript/references.test.js watches a solution over an edit and asserts each project of the second build is handed the very same program object the first returned. tsc -b reads an old program back from .tsbuildinfo either way, so the recorder mock had to record object identity rather than "was there an old program": with that, reverting the change fails the test.

Does this PR introduce a breaking change?

No — same diagnostics, same options.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

n/a — no option changed.

Use of AI

Claude Code wrote the benchmark, measured the three candidate designs, wrote the change, the test and this description; I reviewed all of it.

Rebased onto main now that #341 has landed, so this is one commit. #343 sits on top of it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GzZci4NQeiqwdrVfd7dGXy