TypeScript 7.0 reached a release candidate on June 18, and it is the compiler rebuilt in Go rather than in TypeScript itself, a version Microsoft says runs about 10 times faster than the current TypeScript 6.0. For a toolchain that sits in the inner loop of nearly every large JavaScript project, a change of that size is less about a headline number and more about what disappears from a developer's day: the pauses waiting on a full type-check, and the editor lag that makes a huge codebase feel sluggish.
The candidate installs today with npm install -D typescript@rc, and Microsoft expects a stable build within a month. It has been running against real code for a while: Bloomberg, Canva, Figma, Google, Linear, Miro, Notion, Slack, Vanta, and Vercel are among the teams testing pre-release builds, with some reporting they shave off a majority of their build times. Microsoft ported the existing checker deliberately rather than reimagining it, so the type-checking behavior stays structurally the same as the version it replaces, which is the difference between a rewrite teams can adopt and one they have to relearn.
Native code and shared-memory parallelism also give the compiler new controls. A checkers flag sets how many type-checking workers run, defaulting to four; a builders flag governs parallel project-reference builds; and a singleThreaded flag forces serial execution for debugging. The editor gains as much as the command line: a TypeScript Native Preview extension for Visual Studio Code, built on the Language Server Protocol, delivers the same speedup and, Microsoft says, cuts failing language-server commands by more than 20 times, the kind of reliability fix that is felt more than measured.
The speed comes with a migration cost. The es5 target is no longer supported, baseUrl is gone in favor of paths, the types option now defaults to an empty list instead of pulling in every installed @types package, and rootDir defaults to the current directory. Compilation is only half the toolchain, too: the programmatic API that editors, bundlers, and lint tooling build on will not stabilize until TypeScript 7.1, which Microsoft places several months further out. Teams that depend on that API through custom tooling have a longer wait than the compiler timeline suggests.
The naming hints at how Microsoft wants this to land. TypeScript 6.0 exists mainly to smooth the jump, introducing the new defaults and deprecations ahead of time and shipping a @typescript/typescript6 package so a project can install the old and new compilers side by side and move at its own pace. That staging matters because the payoff is real but the disruption is optional in timing only, not in substance. The open question for the next month is whether a Go compiler that is a faithful port of the old one holds up once thousands of smaller projects, each with their own edge cases, run it in anger.
