TypeScript 7's Go compiler: what the 10x speedup changes
TypeScript 7 rewrites tsc in Go and type-checks the 1.5M-line VS Code repo in 7.5s instead of 78s. Here is what the 10x speedup changes for a dev team.
TypeScript 7 is a native rewrite of the TypeScript compiler in Go that type-checks large codebases roughly ten times faster than the current JavaScript-based tsc. Same language, same type system, same syntax. What changes is the machine underneath: the tool that reads your code and reports type errors now runs as a compiled native binary instead of JavaScript on Node.
If your team waits on a slow tsc --noEmit in CI, or your editor stalls for a second every time it reindexes a large repo, this is the release that removes that tax. Microsoft calls the effort Project Corsa. It shipped as an installable preview in 2026 and is the biggest change to the TypeScript toolchain since the language went self-hosted.
The 30-second version
Microsoft ported the TypeScript compiler and language service from TypeScript to Go. On its own benchmarks the native compiler checks the 1.5-million-line Visual Studio Code codebase in about 7.5 seconds instead of 78, and cuts editor project-load time from roughly 9.6 seconds to 1.2, using about half the memory. The version number for the native toolchain is 7.0. The existing JavaScript compiler continues under the 6.x line while teams migrate. Type-checking is production-ready first, with full code emit and project references following later in the rollout.
Why TypeScript rewrote its compiler in Go
The original compiler is written in TypeScript and runs on Node. That was a deliberate choice: it let the team use the language to build the language, and kept everything in one codebase. The cost is speed. JavaScript runs single-threaded by default, is garbage-collected, and is JIT-compiled at startup, so a cold type-check pays for parsing and warm-up on every run. As codebases grew past a million lines, that overhead became the dominant complaint.
Go was picked for a specific reason, not fashion. The existing compiler leans on shared mutable data structures and heavy graph traversal, which map cleanly onto Go's memory model and goroutines. Anders Hejlsberg, TypeScript's lead architect, has explained that the team wanted a language that let them port the existing code structurally rather than redesign it, and Go's semantics were the closest fit. A Rust rewrite would have meant fighting the borrow checker to reproduce a compiler built around shared pointers. Go kept the port faithful to the original, which is why it landed in roughly a year.
What the 10x actually measures
The headline number is type-checking and build throughput, measured by Microsoft on real projects:
- VS Code (1.5M lines): about 78s down to 7.5s, a 10.4x reduction.
- Editor project load: roughly 9.6s down to 1.2s, about 8x.
- TypeORM: 17.5s down to 1.3s.
- Memory: around half of the JavaScript compiler on the same projects.
Two caveats keep this honest. The gains are largest on big repositories. A 5,000-line side project will not feel a 10x jump, because it was already fast. And the number is compiler throughput, not your whole pipeline: if installing dependencies and running tests dominate CI, a faster type-check shrinks one slice, not the total.
What changes for a dev team
CI stops waiting on the type-checker
On a large monorepo, a pre-push or pre-merge tsc --noEmit gate can run for minutes. Teams that measured the native compiler report that check dropping from around five minutes to under fifteen seconds. That turns type-checking from a step you batch and dread into one you can run on every save.
Editors stop lagging on big repos
The slowest part of editing large TypeScript is not compilation, it is the language service: autocomplete, go-to-definition, and error squiggles that stall while the server reindexes. The native language service cuts project-load and response times by a similar factor, so a big repo starts to feel like a small one.
Fewer reasons to split a codebase for speed
Plenty of teams break a monorepo into packages purely to keep type-checking tolerable. When a single check of more than a million lines finishes in seconds, that pressure eases. The architecture decision goes back to being about ownership and boundaries rather than compiler performance.
What it does not change
The type system is identical. TypeScript 7 is a reimplementation, not a redesign: the same inference, the same errors, the same tsconfig.json. Microsoft reports type-checking compatibility above 98% against the existing compiler, with a small set of edge cases tracked in the open. Your strict-mode settings and existing configuration carry over unchanged.
What trailed the type-checker in the rollout was the rest of the toolchain: JavaScript and declaration-file emit, --build mode with project references, and the full set of language-service features. That is why the practical entry point is tsgo --noEmit as a fast type-check next to your existing tsc for emit, rather than a wholesale swap on day one.
Part of a wider move to native tooling
TypeScript 7 is one instance of a pattern running through frontend tooling in 2026: performance-critical JavaScript tools rewritten in a compiled language. Bundlers and linters moved to Rust and Go for the same reason the compiler did, because the workloads are large, repetitive, and parallelizable. For a team, the takeaway is that build steps that used to justify splitting projects or caching aggressively are getting an order of magnitude faster on their own. We factor that into stack choices for new work: a native type-checker changes how much a large TypeScript surface actually costs to maintain. It also pairs with the discipline of keeping the dependency graph lean, since a fast checker still has to read everything you import.
When to adopt it, and when to wait
Adopt it now as a type-checker if you have a large codebase and CI type-check times measured in minutes. Run tsgo --noEmit in parallel with your current build and compare the two. The risk is low, because it does not produce the output you ship. Wait before making it your only compiler if you depend on declaration emit for a published package, on project references for build orchestration, or on an editor extension that has not been ported yet. Treat 2026 as the year you add it as a fast check, and the next cycle as the year it becomes the default.
How to try it today
The native compiler ships as @typescript/native-preview and exposes a tsgo binary. Install it as a dev dependency, then run tsgo --noEmit against a project with an existing tsconfig.json. Because it reads the same configuration, you can wire it into CI as an extra job and keep your current tsc step until emit and project references are stable for your setup. There is an experimental editor extension for the native language service if you want to feel the responsiveness change directly.
Where this sits in your stack decisions
A native type-checker changes the math on a few adjacent choices. Strict mode gets cheaper to run, so the reasons to defer it shrink. Monorepo boundaries stop being a performance workaround and go back to being an ownership question. And the case for splitting a large app into services purely to keep local builds fast weakens. None of this is a reason to rearchitect today. It is a reason to stop treating type-check time as a fixed cost when you plan the next codebase, because in 2026 it stopped being one.
Sources
Frequently asked questions
Is TypeScript 7 the same thing as tsgo and Project Corsa?
They are three names for one effort. Project Corsa is Microsoft's internal codename for porting the compiler to Go. tsgo is the binary you run, distributed in the @typescript/native-preview package. TypeScript 7.0 is the public version number the native toolchain ships under, while the existing JavaScript compiler continues on the 6.x line. When people say TypeScript 7, tsgo, or the native compiler, they mean the same Go rewrite.
Will TypeScript 7 break my existing code or config?
It should not. TypeScript 7 reimplements the same type system, so it reads the same tsconfig.json, reports the same errors, and honors the same strict-mode flags. Microsoft measures type-checking compatibility above 98% against the current compiler, with the remaining edge cases tracked publicly. The safe way to confirm it on your codebase is to run tsgo --noEmit alongside your existing tsc and diff the reported errors before you rely on it.
Do I need to learn Go to use TypeScript 7?
No. Go is the language the compiler is written in, not a language you touch. You keep writing TypeScript, keep your tsconfig.json, and run tsgo the same way you run tsc. The Go rewrite is an implementation detail that shows up only as speed. The one place it surfaces is distribution: the compiler ships as a native binary per platform instead of pure JavaScript, so your CI image pulls a platform-specific package.
Is the 10x speedup real for a small project?
Not really, and that is fine. The 10x figure comes from repositories in the millions of lines, where the old compiler spent most of its time on parsing and warm-up. A small app that already type-checks in a second or two will see a smaller absolute gain, because there was little to reclaim. The teams that feel the difference most are the ones running long CI type-checks or editing large monorepos where the language service used to stall.
Related articles
Studio
Start a project.
One partner for the whole build. Faster delivery, a modern stack, lower cost.