TypeScript has done the thing everyone assumed it never would: it rewrote the compiler in another language. TypeScript 7.0 — the release the team spent 2025 building under the codename Project Corsa — is a from-scratch port of the compiler and language service from TypeScript to Go, and it is roughly ten times faster than the compiler you are using today. The release candidate landed on the TypeScript blog in mid-June 2026, and the stable release followed about three weeks later.

The remarkable part is what did not change. This is not a new type system, a new config format, or a new set of rules to learn. It is the same checker, moved.

Why Go, and why a rewrite

The existing compiler — now referred to internally as Strada — is written in TypeScript and runs on a JavaScript engine. That is elegant (the type-checker is type-checked by itself) but it leaves performance on the table: no real parallelism, GC pauses on large programs, and a startup cost you pay on every editor session. Go gives the team native code, actual threads, and tighter control over memory layout, which is where most of the speedup comes from.

Critically, they did not redesign the checker. Corsa moved the existing structure out of the TypeScript codebase and into Go file by file, deliberately preserving the same algorithms and data structures — and therefore the same type-checking results. If your code type-checks on 5.x, it type-checks the same way on 7.

Where you feel the 10x

Two places. The first is your editor: the language service is what powers hover, go-to-definition, and the red squiggles, and on a large project it is the difference between instant and a spinner. The second is CI, where a full tsc --noEmit on a big monorepo is often the slowest job in the pipeline. Cutting a two-minute type-check to twelve seconds changes how often people are willing to run it.

You can try the native compiler alongside your existing one — it installs as a separate binary, so nothing about your current setup has to change to benchmark it.

# during the preview it shipped as a separate package
npm install -D @typescript/native-preview

# run the native binary (tsgo) against your existing config
npx tsgo --noEmit

# compare against the classic compiler
time npx tsc --noEmit
time npx tsgo --noEmit

What to check before you switch CI over

The type-checking is a faithful port, but the surrounding ecosystem is where you should look. Anything that plugs into the compiler through its API — custom transformers, some monorepo build tools, a few editor extensions — targets the old JavaScript API surface, and those integrations need native-compatible versions. If your build is a plain tsc plus a bundler, you have almost nothing to worry about. If it leans on ts-patch, custom transformer plugins, or a tool that imports from typescript directly, test those paths first.

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "typecheck:native": "tsgo --noEmit"
  }
}

Run both for a week. If they agree on every project (they should), delete the slow one.

When to adopt

For editor use, now — a faster language service is pure upside and does not touch your build output. For CI type-checking, as soon as you have confirmed your compiler-API dependencies have caught up. For emit (actually producing JavaScript), most teams already hand that to a bundler like esbuild or the newer Rust toolchains, so the compiler is only doing type-checking anyway, which is exactly the part that got faster.

The bigger picture is that the era of "type-checking is the slow part of my build" is ending. When a full check is measured in seconds, you run it on every commit, gate every PR on it, and stop treating types as a thing you verify occasionally. That is the real change — not the language, but how tight the loop around it gets.