The Native Compiler Reaches Release Candidate
Microsoft has published a release candidate for TypeScript 7.0, the version that swaps the language's long-standing JavaScript-based compiler for a native port written in Go. This is the milestone the TypeScript team has been building toward all year, first previewed, then shipped in beta, and now hardened to the point where a full release is planned within the next month. Developers can install it today with npm install -D typescript@rc. After a year of anticipation and skepticism about rewriting a compiler in a different language, the RC is the signal that the effort has cleared its riskiest phase and is close to production readiness.
The decision to port to Go rather than rewrite in Rust or C++ drew plenty of commentary when it was announced, but the pragmatic logic has held up. Microsoft says the Go codebase was methodically ported from the existing implementation rather than rewritten from scratch, and that its type-checking logic is structurally identical to TypeScript 6.0. That is an important claim for anyone worried about behavioral drift. A faithful port that preserves type-checking semantics is a very different risk profile from a ground-up reimplementation that might subtly disagree with the old compiler on thousands of edge cases in real codebases.
Where the Tenfold Speedup Comes From
The performance claim is the reason anyone cares: Microsoft says TypeScript 7.0 is often about ten times faster than its predecessor. Two things drive that. The first is simply native code speed, since a compiled Go binary runs the type checker far faster than the same logic interpreted and JIT-compiled from JavaScript. The second, and arguably more consequential, is shared memory parallelism. As the team put it, "TypeScript 7.0 performs many steps in parallel, including parsing, type checking, and emitting," work that the JavaScript-based compiler executed largely on a single thread because of the runtime's constraints.
For small projects a tenfold speedup is a pleasant convenience. For the monorepos and enterprise codebases where TypeScript now dominates, it is transformative. Type checking is on the critical path of every editor interaction, every continuous integration run and every build, and when a full check takes minutes, that latency compounds across a large team into real lost time and degraded developer experience. Collapsing multi-minute checks toward the tens-of-seconds range changes how tight the feedback loop can be, and it removes one of the standing arguments that large organizations used against adopting strict typing across their entire codebase.
Running Side by Side With 6.0
Microsoft has been careful about migration mechanics, which is where compiler transitions usually go wrong. Because a stable programmatic API will not arrive until TypeScript 7.1, the team made it a priority that 7.0 can run alongside 6.0 without the two versions fighting over which binary owns the tsc command. A compatibility package, published as @typescript/typescript6, provides an executable named tsc6, so teams can install both and route different parts of their toolchain to whichever compiler they need during the transition. That is a mature acknowledgment that nobody flips a large organization to a new compiler overnight.
This side-by-side story is what makes the RC genuinely adoptable rather than a preview to admire from a distance. A team can point their build at the fast new compiler for a speed win while keeping the old one available for any tool that depends on the programmatic API that is not yet stable. It de-risks the upgrade by turning it into an incremental, reversible change rather than a cliff. We would encourage engineering leaders to have a team try the RC against their largest package this month, because the migration friction is exactly the thing that only reveals itself on a real codebase, not a benchmark.
What Is Not Ready Yet
The most important caveat is the deferred programmatic API. Much of the TypeScript ecosystem, from linters to bundlers to editor plugins, does not just shell out to the compiler; it imports the TypeScript API and calls into it directly. That surface will not be stable until 7.1, which means some tooling will lag the 7.0 release until the API lands and maintainers migrate. Teams with heavy investments in custom TypeScript-based tooling should audit which of their tools depend on the programmatic API before assuming a clean cutover, because for them the meaningful date is 7.1, not 7.0.
That staging is deliberate and, we think, correct. Getting the compiler binary fast, correct and side-by-side installable is the hard prerequisite, and rushing an unstable API out alongside it would have created churn across the ecosystem for years. By decoupling the two, Microsoft lets everyone benefit from the speed of 7.0 now while giving tool authors a stable target to code against once 7.1 ships. It is a reminder that a language toolchain is not just a compiler, it is an ecosystem, and that the health of the transition depends as much on the plugin authors as on the core team.
What It Means for Large Codebases
Step back and the significance is larger than one release. TypeScript is arguably the most widely used typed language layered on top of a dynamic one, and its performance ceiling has been set for a decade by the fact that its compiler ran on the very runtime it was checking. Moving the compiler to native Go breaks that ceiling and puts TypeScript's tooling performance in the same conversation as compiled languages. For platform teams that maintain shared build infrastructure, faster type checking means cheaper CI, faster editor feedback and fewer complaints about the tax that strict typing imposes on developer velocity.
The strategic read is that Microsoft is defending TypeScript's position at the exact moment alternatives are trying to peel developers away with speed arguments. Faster runtimes and faster tools have been the marketing wedge for a wave of JavaScript ecosystem challengers, and a compiler that is an order of magnitude quicker removes performance as a reason to look elsewhere. With the RC in hand and a full release promised within the month, the practical advice is straightforward: pilot it now on your heaviest project, inventory your dependence on the programmatic API, and plan the real rollout around the 7.1 milestone.
