TypeScript 7.0 Beta shipped April 21, 2026. The compiler is now written in Go. The numbers are not incremental improvements. They are a category shift.
On the TypeScript compiler itself (~400k lines of TypeScript), tsgo runs 10.8x faster overall, type-checks 30x faster, and uses 2.9x less memory. Sentry’s codebase drops from 133 seconds to 16. Editor startup goes from 9.6 seconds to 1.2. Bloomberg, Canva, Figma, Google, Slack, and Vercel are already running it against production codebases. This is not a preview. It is a working compiler with real receipts.
The natural conclusion: build tooling matters less now. If type checking is 10x faster, why invest in distributed build infrastructure?
That conclusion is backwards. The build harness matters more now, not less.
The wall that builders hits
tsgo’s --builders flag runs type checking in parallel across Go goroutines on a single machine. Goroutines share memory. The type graph lives in shared address space, so coordination is cheap. There is nothing to serialize.
Cross-machine, all of that disappears.
You cannot share Go’s in-process type graph between two machines. It is enormous. It is not designed for serialization. It changes constantly during a check run. Sending it over the wire is not “hard.” It is architecturally incompatible with how tsgo works.
Type checking is not embarrassingly parallel. A file’s types depend on every file it imports, transitively. On one machine, tsgo resolves those transitive dependencies through shared memory pointers. Across machines, you would need to serialize the type state, transfer it, reconstruct it on the other side, and do this for every file whose imports cross a machine boundary. The cost is not “some network latency.” It is a fundamental mismatch between tsgo’s execution model and the realities of distribution.
tsgo solves single-machine type checking. It does not solve distributed type checking. The bottleneck just moved.
The package boundary as the distribution contract
The answer is not to distribute files. It is to distribute packages.
Each package in a monorepo has a public type surface: its .d.ts output. When package A depends on package B, A only needs B’s .d.ts to type-check against. Not B’s source files, not B’s internal type graph, not the transitive closure of B’s dependencies. Just the declaration file that describes the public interface.
This is the inter-machine type contract. The harness resolves the package DAG, type-checks packages in topological order across workers, and ships .d.ts artifacts between them. Each worker runs tsgo locally (fast, parallel, shared-memory) and produces a .d.ts that the next worker can consume.
Two compiler flags make this clean. isolatedModules ensures every file can be type-checked and emitted independently, without resolving types from other files at check time. isolatedDeclarations ensures each package can produce its .d.ts without deeply resolving its dependencies’ internals.
Without these flags, the package’s type surface leaks internal details that require the full source of every dependency to resolve. With them, the .d.ts is self-contained. The package boundary becomes a clean distribution boundary.
The parallelism stack
Parallelism compounds across three levels. Each multiplies.
Per-file: tsgo with isolatedModules checks each file independently within a package. This is the 10x that ships today. Gains scale with codebase size: 4x under 10k lines, 8.8x at 100k-500k, roughly 10x at 500k+.
Per-package: The harness orders packages by the dependency graph and runs independent branches concurrently. A 200-package monorepo with a critical path of 5 hops means up to 40 packages running at the same time.
Per-machine: The harness distributes DAG shards across build workers. Each worker runs tsgo locally. The only inter-machine payload is the .d.ts artifact.
The theoretical speedup: 10x (tsgo) × package parallelism factor × machine count, bounded only by the critical path through the DAG. Everything off the critical path is pure parallel win.
tsgo gives you the first level. The harness gives you the other two. Without the harness, 10x is the ceiling. With it, the ceiling is much higher.
The discipline problem
Here’s where the story gets structural. The same code discipline that unlocks tsgo’s per-file parallelism is the same discipline that unlocks the harness’s distributed parallelism. Both require isolatedModules. Both break on the same failure mode: files with implicit dependencies on the full type graph.
Teams that built without isolatedModules cannot benefit from tsgo’s parallelism. Those same teams cannot benefit from distributed execution. The discipline failure blocks both paths simultaneously.
This looks like a people problem. Developers should have enabled isolatedModules from day one. They should have known better.
But at the bottom, it’s a tooling problem. The tooling never enforced isolation. The default was isolatedModules: false. So codebases accumulated implicit full-graph dependencies for years, one file at a time, with no warning.
In the middle, it looks like a people problem. In truth, it’s a tooling problem masquerading as a people problem masquerading as a tooling problem.
The answer is a build harness that enforces isolatedModules as a build requirement. Not a guideline. Not a recommendation. A gate. Packages that can’t satisfy isolation get flagged at configuration time, before they ever reach the build queue.
What the harness still does
tsgo handles type checking on a single machine. That is one piece. Here is the rest.
A 10x faster type checker running unscoped across 500 packages is still 50x slower than a scoped run across 10 affected packages. Speed without scoping is waste. And scoping is a harness concern, not a compiler concern.
tsgo makes the type-check step fast. The harness makes the build system intelligent.
Where the bottleneck lives now
The single-machine type-checking problem is solved. tsgo solved it. Congratulations to the TypeScript team. This is genuinely excellent work.
The remaining bottleneck is coordination: which packages to check, in what order, on which machines, with what cached. That is what a build harness does. tsgo made the harness more important by making everything else fast enough that coordination is the dominant cost.
When type checking was slow, the harness was an optimization. Now that type checking is fast, the harness is the architecture.