If you've worked in a large TypeScript codebase, you know the feeling. You save a file, tab away, and wait for the red squiggles to catch up. On a big monorepo, tsc --noEmit in CI is the slow step everyone learned to stop watching. The type checker was written in TypeScript, running on a single JavaScript thread, and there's only so fast that can go.
That's the thing that just changed. On July 8, 2026, Microsoft shipped TypeScript 7.0: the same compiler you already use, rewritten from the ground up in Go. The headline number is builds that run 8 to 12 times faster, and after living on the preview for a while, that number holds up.
What TypeScript 7 actually is
TypeScript 7 is a native port of the compiler and tooling. There's no new type system here, no new syntax. The team took the existing checker and methodically ported it to Go, keeping the logic structurally identical to the JavaScript version. The RC announcement puts it plainly: the Go codebase "was methodically ported from the existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0."
That's the part worth internalizing before anything else. Your types don't change. The inference you rely on, the errors you see, the edge cases you've memorized: all the same. Microsoft ran the two implementations against roughly 20,000 test cases and found that in all but 74, TypeScript 7 produces the same errors as TypeScript 6. This is a performance release wearing a major version number, not a language release.
Why Go, of all things
This was the question everyone asked when the port was announced back in March 2025. Why not Rust? Why not C#, Microsoft's own language?
The design notes give a practical answer. The compiler does an unusually large amount of graph work, walking trees up and down through polymorphic nodes, and Go makes that ergonomic. It gives you control over memory layout and allocation without forcing every line of the codebase to think about ownership. And because a batch tsc run terminates when it's done, the compiler can lean on Go's garbage collector cheaply, or skip collection almost entirely, since the process exits and the OS reclaims everything anyway.
There's also the boring reason, which is usually the real one: idiomatic Go looks a lot like the existing TypeScript codebase. Functions and data structures, not deep object hierarchies. That resemblance is what made porting hundreds of thousands of lines tractable instead of a multi-year rewrite. Anders Hejlsberg, who has been on this since the start, has described Go as the lowest-level language that still offered native code, a garbage collector, and good concurrency without fighting the transition from TypeScript's coding style.
How much faster is TypeScript 7?
Here's what the speedup looks like on real projects, measured for the 7.0 release against TypeScript 6:
| Project | TS 6 | TS 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 |
A full check of the VS Code codebase went from over two minutes to about ten seconds. Memory use dropped too, somewhere between 6% and 26% depending on the project.
The build-time number is the one that gets quoted, but the one you'll feel every day is editor responsiveness. Loading the VS Code project in the editor used to take around 9.6 seconds before the language service was ready; on the native port it's about 1.2. That's the gap between "the squiggles show up when I need them" and "I've already tabbed away."
Where does the speed come from? Two places. Native code is faster than JIT-compiled JavaScript for this kind of work, and Go lets the compiler use shared-memory multithreading that the single-threaded JavaScript version simply couldn't. Build mode now runs multi-threaded on a single project and compiles multiple projects in parallel, so the whole graph gets to use your cores instead of one of them.
How to install TypeScript 7
At GA, the compiler ships from the package you already have. Install the latest typescript and the binary is still tsc:
npm install -D typescript
If you were on the preview before GA, note that the names have settled. During the preview the package was @typescript/native-preview and the binary was tsgo, run like this:
npx tsgo --project ./src/tsconfig.json
From the RC onward that folds back into the normal typescript package and the tsc command you've always used, so most projects change a version number and nothing else. The typescript-go repo that housed the port is expected to merge back into the main microsoft/TypeScript repository over time.
The 6.0 / 7.0 split
The version jump from 5.x is deliberate, and it comes with a plan. TypeScript 6.0, released in March 2026, is the final JavaScript-based version. There's no 6.1 on the roadmap, only patch releases for security fixes or serious regressions. It exists as the bridge: 6.0 shipped the new defaults and marked a set of things deprecated, giving you a release to clean up against while still running the old, familiar implementation.
TypeScript 7.0 then adopts those 6.0 defaults and turns the deprecations into hard errors. A few compiler options are gone or changed:
target: es5 is removed.baseUrl is no longer supported.types now defaults to [] instead of pulling in everything under node_modules/@types.rootDir defaults to ./.
If a jump straight to 7.0 surfaces too much at once, there's a side-by-side @typescript/typescript6 package so you can keep the old compiler available while you migrate.
What doesn't work in TypeScript 7 yet
This is the part to be honest about, because it's where the release will actually bite.
The editor story moved to a Language Server Protocol architecture, which is a good long-term direction. But TypeScript 7 does not yet expose a stable programmatic API, and a lot of the ecosystem is built on that API. The concrete fallout: template type-checking for Vue, Svelte, Astro, MDX, and Angular isn't supported on TypeScript 7 yet. Those tools reach into the compiler's internals to type-check the parts of your app that live outside .ts files, and until the public API stabilizes, they can't do that against the Go implementation.
So if you're building a Vue or Svelte app, or anything that leans on a framework's language tooling, the 10x number is real but you can't fully collect it yet. The compiler is ready; the layer your framework plugs into isn't. This is worth checking against your own stack before you upgrade, since it's the difference between a version bump and a broken editor.
Should you upgrade?
If you've got a plain TypeScript project, a library, a Node service, a build script, the answer is easy: yes, and soon. The type checking is the same, the CI step gets dramatically faster, and the migration is mostly a version bump plus whatever 6.0 already warned you about.
If you're in a framework app that depends on template type-checking, wait and watch. Track the programmatic API work, see when your framework's tooling lands support, and upgrade then. There's no rush and no downside to letting it settle.
Either way, this is the most significant thing to happen to TypeScript's infrastructure in years. The type system stayed still on purpose so that the thing underneath it could get an order of magnitude faster. That's a rare kind of release, and the wait for tsc that I opened with is about to stop being a thing you plan your day around.