TypeScript 7 was rewritten in Go: what changes in your build and what stays the same

What happened

Microsoft announced in March 2025 that it was porting the TypeScript compiler to Go. The result shipped as TypeScript 7.0 on July 8, 2026, after a release candidate in June.

The number that circulated everywhere: type-checking the VS Code codebase dropped from roughly 125 seconds on TypeScript 6 to a little over 10 seconds on 7 — nearly 12x. Across projects in general, Microsoft describes the gain as somewhere between 8x and 12x on full builds, coming from three places: native code, shared-memory multithreading, and new optimizations the previous runtime did not allow.

The detail that matters most: it is a port, not a rewrite

The distinction sounds semantic, but it is the most relevant fact about this release. The team ported the compiler line by line, preserving type-checking semantics. That means code that compiled before compiles now, with the same errors and the same inferred types.

Had it been a rewrite, migration risk would be high: subtly different behavior in generic inference is exactly the kind of thing that breaks a large project in hard-to-trace ways. Being a port, the risk moves — out of your code and into the ecosystem around the compiler.

Where migration actually stalls

The practical blocker is not your tsconfig.json. It is whatever depends on the compiler's programmatic API:

• ESLint rules using type information (@typescript-eslint with parserOptions.project).
• Code generators and transformers that load the compiler as a library.
• Build tools and frameworks that instrument the type-check process.

The stable programmatic API did not ship in 7.0 — it is expected in 7.1. Until then, any tool importing the compiler as a module needs an adapted version. Before scheduling the migration, the right inventory is not "which features do I use," it is "which packages in my project talk to the compiler internally."

A migration strategy without drama

The lowest-risk path is running both in parallel for a while:

1. Keep your current tsc as the source of truth in CI — that is what fails the PR.
2. Add a parallel job running the native compiler, marked non-blocking.
3. Compare the output of both across a few weeks of real work, not a single commit.
4. When the parallel job is clean and dependent tooling has support, flip them: the native one blocks, the old one goes parallel.
5. Only then remove the old one.

That plan costs a few CI minutes per PR and removes almost all of the risk.

What the speedup actually buys

Worth calibrating expectations. The jump is in type-checking, not necessarily in your total build time. If your pipeline's bottleneck is bundling, tests, or deployment, a 10x faster type-check improves the number without changing your life.

Where the difference is genuinely felt is in the editor. Fast type-checking means autocomplete that does not hang, instant go-to-definition in a large monorepo, and error feedback while you still remember what you were thinking. None of that shows up in a pipeline metric — and it is by far the biggest win in this release.

What to do this week

If your project is small and dependencies are few, testing the native compiler locally takes ten minutes and probably already works. If you maintain a monorepo with typed linting and code generation, the useful work right now is mapping which tools depend on the compiler API and tracking their support. Migrating too early in that scenario trades ten seconds of build time for an afternoon of tooling debugging.