TypeScript 7: What the Go Rewrite Actually Changed
TypeScript was built out of itself for a long time. The tsc compiler and the language service were written in TypeScript, compiled to JavaScript, and run on Node.js. The design was elegant, and its ceiling was just as clear. Once a codebase reaches millions of lines, type checking and editor startup take real time.
Microsoft changed that foundation in TypeScript 7. The compiler and the language service were moved to Go while keeping the structure and behavior of the existing implementation as intact as possible. The new implementation runs as native code and parallelizes over shared memory. Full builds came out 8 to 12 times faster.
TypeScript 7 went through a beta in April 2026 and an RC in June, and shipped on July 8. There is no separate preview package anymore. You install it the way you always did.
npm install -D typescript
npx tscWhy Go and not Rust
As soon as the port was announced, people asked whether Rust would not be the better fit if performance was the goal. The team did not pick Go for raw execution speed. They needed a language that let them carry the existing compiler structure over as-is and keep the two implementations behaving identically.
The TypeScript compiler is written around functions rather than classes. The AST and the symbol table form a dense graph of mutual references, and object lifetimes are not simple. Moving that shape to Rust would likely have meant redesigning a large part of it around ownership and lifetimes.
Go, on the other hand, has garbage collection. Data structures with cyclic references are reasonably natural to express, and existing TypeScript code can be carried over with a similar structure. Go also makes native binaries for many platforms easy to produce and has solid concurrency support.
The important part is that this was not a rewrite in the sense of designing a new compiler from scratch. The team ported the structure and the type-checking logic of the existing code as faithfully as they could. The goal was not better language rules. It was the same output for the same input, much faster. TypeScript 7.0 RC announcement, the Why Go? discussion
How much faster it actually got
The measurements published with the stable release make the difference plain.
| Project | TypeScript 6 | TypeScript 7 | Speedup |
|---|---|---|---|
| VS Code | 125.7s | 10.6s | 11.9x |
| Sentry | 139.8s | 15.7s | 8.9x |
| Bluesky | 24.3s | 2.8s | 8.7x |
| Playwright | 12.8s | 1.47s | 8.7x |
| tldraw | 11.2s | 1.46s | 7.7x |
Early numbers from the preview stage pointed the same way. VS Code, at roughly 1.5 million lines, dropped from 77.8s to 7.5s, and Playwright from 11.1s to 1.1s. TypeORM went from 17.5s to 1.3s.
Two changes produce the speedup. First, the compiler runs as native machine code instead of JavaScript. On top of that, parsing, type checking, and emit are spread across several threads.
The default number of type checkers is 4. On machines with many cores, raising --checkers can buy more. In the official measurements, --checkers 8 brought the VS Code build down to 7.51s. More checkers also mean more memory, though. In a resource-constrained environment such as CI, lowering the number may be the better call.
Memory use dropped as well, but “about half” is too broad a claim to make. The figures published with the stable release show a reduction of roughly 6 to 26 percent depending on the project. Memory and speed both depend on how the code is structured and how parallelism is configured, so measuring on your own repository is the safe move. Announcing TypeScript 7.0, the early native port measurements
Editors get faster too
This is not only about tsc. The language server that editors talk to was rebuilt on Go as well.
The new server speaks the standard Language Server Protocol instead of a TypeScript-specific protocol. It handles multiple requests concurrently and provides auto-imports, hover information, inlay hints, code lenses, go-to-definition, semantic highlighting, and organize imports.
In the early measurements, loading the VS Code project in the editor went from 9.6s to 1.2s. Canva, which put the stable release into production use, reported that the time to see the first error in the editor fell from about 58 seconds to about 4.8 seconds. Slack cut CI type-checking time from roughly 7.5 minutes to 1.25 minutes.
Adopting LSP matters outside VS Code as well. An editor no longer has to implement the old tsserver protocol to talk to the TypeScript language server. Integration quality and feature coverage still vary by editor, so check that editor’s own documentation.
What to check before migrating
TypeScript 7 preserves TypeScript 6’s type-checking rules and command-line behavior as much as it can. The safest path is therefore to move to 6 first, clear the deprecation warnings and configuration changes, and only then go to 7.
In particular, settings that were deprecated in TypeScript 6 become errors in 7. target: es5, moduleResolution: node, moduleResolution: classic, baseUrl, and module: amd are no longer supported. Defaults changed too: strict is on by default, and the default for types is now an empty array. For an existing project, tsconfig.json is the first thing to review.
The bigger constraint is the programmatic API. TypeScript 7.0 does not ship a stable compiler API. Tools that import the typescript module directly, such as typescript-eslint, custom transformers, and some webpack loaders, will need the TypeScript 6 API for now. Microsoft ships a @typescript/typescript6 compatibility package for exactly that.
Tools that embed the TypeScript language service, such as Vue, Svelte, Astro, and MDX, along with Angular’s template type checking, cannot take full advantage of TypeScript 7 yet. Those projects may need a split setup: TypeScript 7 for CLI type checking, TypeScript 6 alongside it for the editor and related tooling. The new programmatic API is planned for TypeScript 7.1.
Conclusion
What matters in TypeScript 7 is not new syntax. It is a swap of the execution foundation that finishes the same type checking in far less time.
A typical application will likely get the speedup just by bumping the typescript package. Tools that depend on the compiler API or on language service plugins may still need TypeScript 6 in the mix.
So the migration order is simple. Clear the deprecated settings and behaviors under TypeScript 6 first. Then put TypeScript 7’s tsc into CI and your local environment and measure speed and memory. Finally, check compatibility separately for anything wired into compiler internals: ESLint, framework plugins, custom transformers.
You do not know until you measure your own repository
Every multiplier above came from somebody else’s repository. As noted above, speed and memory depend on how the code is structured and how parallelism is set up. Start with what one laptop can answer.
Measure your own multiplier. Bump the typescript package, run npx tsc, and write the number down next to the time you had before. Then sweep --checkers across 2, 4, and 8 and fill in build time and peak memory in the same table. The default is 4 and the official numbers were best at 8, but more checkers also mean more memory, so the answer changes wherever a CI container has a memory ceiling. A small codebase, like a course project, may show almost no gap at all, and that is worth knowing too.
Build a deprecated-settings scanner. A short script that reads tsconfig.json and flags target: es5, moduleResolution: node, moduleResolution: classic, baseUrl, and module: amd. Following extended configs and reporting the merged result is trickier than it sounds. Run it across several repositories and you get your migration order for free.
List the dependencies that import typescript directly. This is where the missing programmatic API actually bites. Pick out the dependencies that take typescript as a peer or direct dependency, and that list is your reason for keeping TypeScript 6 around a while longer. Checking the list beats putting off the guess.
If I had to pick one, it would be the third. That multipliers vary by repository has been said plenty of times already, but the list of tools stuck behind the compiler API differs from team to team, and I have yet to see anyone collect those lists in one place. If you have measured a number or pulled such a list, tell me. Enough of them together would make an article on their own.
References
- A 10x Faster TypeScript (TypeScript Devblog)
- Announcing TypeScript 7.0 Beta (TypeScript Devblog)
- Announcing TypeScript 7.0 RC (TypeScript Devblog)
- Announcing TypeScript 7.0 (TypeScript Devblog)
- Why Go? · microsoft/typescript-go Discussion #411
- microsoft/typescript-go (GitHub)
- Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C# (The New Stack)