TypeScript 7 Went Native — Here's What Actually Changes

Last week I ran tsc --noEmit on our main app and went to make coffee. By the time I came back, it was still running. Ninety seconds of staring at a blinking cursor, every single time I touched a shared type. That was just the check — the editor was doing its own slow dance in the background, re-indexing the whole project whenever I switched branches.

Then I tried the native preview. The same command finished in under nine seconds.

That's the story of TypeScript 7: the compiler is no longer written in JavaScript. It's written in Go now, and it changes more about your daily workflow than any type-system feature could. Here's what actually changes — and what doesn't, because a lot of the hype skips that part.

What Actually Happened

Microsoft didn't announce a new type system or a new language. They rewrote the compiler itself. The JavaScript-based tsc that shipped with TypeScript 5.9 was the last of its line. TypeScript 7 is the native port, built in Go, running as a real compiled binary instead of a giant JavaScript program interpreted at runtime.

That's why the version numbers jump straight from 5.9 to 7. There was never a 6. The team decided the rewrite was significant enough to skip a number, and honestly, for anyone who's waited on a big type-check, it earns it.

Microsoft's own benchmarks put the native compiler at roughly 10x faster type checking. Their demo checked the entire VS Code codebase — over a million lines of TypeScript — in about 13 seconds. The JavaScript compiler took minutes. My own project went from 90 seconds to 8.6, which tracks.

Why the Old Compiler Was Slow in the First Place

The old compiler wasn't slow because TypeScript's type checking is inherently expensive. It was slow because the checker ran inside a JavaScript runtime, which brings two problems.

First, JIT warm-up. V8 has to interpret and optimize the compiler code itself before it gets fast. On a cold start, you eat that cost every single time. That's why short-lived commands like tsc --noEmit in CI felt disproportionately slow — they never lived long enough to benefit from the warm-up.

Second, memory pressure. A big project's type graph is huge, and JavaScript's garbage collector spends real time managing all those objects. The Go version lays out data more densely and cleans up after itself with a fraction of the overhead. Lower memory, less GC churn, faster everything.

The core algorithm is the same. The constraint solver, the inference rules, the structural typing — all of it carried over. It's the same TypeScript you know, just no longer running on a JavaScript interpreter that was never designed to be a compiler runtime.

What Changes for You

Three things, in my experience, and they're all the ones you feel daily:

• Builds. Type-checking was the last slow step in the frontend pipeline. Everything else — bundling, minifying, tree-shaking — got fast years ago. Now the type-check is fast too. CI type-check jobs that took three minutes take twenty seconds.
• The editor. This is the sleeper win. VS Code's language server uses the same compiler, so the native speedup lands in IntelliSense, go-to-definition, and project load. Files that used to take a second to respond now snap. On a big monorepo, the editor finally feels like it's running on a local project instead of a remote one.
• Watch mode. tsc --watch was always the poor cousin of bundler watch modes. Now it's genuinely usable for incremental type-checking while you code, which pairs well with noEmit projects.

One more subtle change: because checking is cheap, you start running it more. I added a type-check to my pre-commit hook, something I would never have done when it cost ninety seconds each time. Cheap checks change your habits, and better habits beat better tooling every time.

What Doesn't Change

This is the part the hype posts skip, so pay attention.

Your TypeScript code is exactly the same. TypeScript 7 is not TypeScript 6-with-new-syntax. There are no new type features, no changed inference rules, no "Go-flavored" anything. If your code compiles on 5.9, it compiles on 7 — the language semantics are identical. The rewrite was about performance, not behavior.

Your tsconfig.json mostly survives. The vast majority of options carry over unchanged. The caveat: deprecated flags that had been warning for years finally got deleted. If you were living with moduleResolution: node, importsNotUsedAsValues, or old-school out flags in your config, the upgrade will tell you, loudly, and it's a ten-minute cleanup.

Bundlers don't care. Vite, esbuild, and webpack never type-checked your code anyway — they strip types and move on. If your build felt "TypeScript-y," it wasn't checking anything. That's been true for years. TypeScript 7 doesn't change it, which is exactly why running a real tsc --noEmit in CI matters more than ever.

Migrating a Real Project

The upgrade itself is boring, which is the best thing I can say about it:

npm install -D typescript@^7
npx tsc --noEmit

That's the whole migration for most projects. Fix whatever the deleted flags complain about, then enjoy the speed.

Two things to check beyond the obvious:

• Tooling that uses the compiler API. Tools like ts-node, ts-jest, and typescript-eslint hook into the compiler's JavaScript API, and the native rewrite changed that surface. By now the major ones ship support, but check the version you're on before upgrading. If you use typescript-eslint, make sure you're on a release that declares TypeScript 7 support — the error messages when you get this wrong are unhelpful.
• Watch for the removed flags. Grep your config and your build scripts for moduleResolution: node, out, importsNotUsedAsValues, and charset. Replace them with modern equivalents before you switch, not after.

// tsconfig.json — the modern basics that just work on TS7
{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler",
    "target": "es2022",
    "strict": true,
    "noEmit": true
  }
}

One real gotcha: if you're on a monorepo with workspace tooling that shells out to tsc by name, make sure your package manager resolves the new binary everywhere. I've seen CI pipelines where one workspace picked up TypeScript 7 and another stayed on 5.9, and the type errors that surfaced were confusing until we realized the two were checking different things.

Should You Upgrade Today?

For most projects: yes, and it's a low-risk one. The language is identical, the config migration is small, and the payoff shows up in every single command you run. If you're on a large codebase or a monorepo, the editor speedup alone is worth the ten minutes.

The main reason to wait is exotic tooling. If you depend on a plugin or a build tool that digs deep into the old compiler API, check its TypeScript 7 support first. For everyone else, there's no real reason to sit on 5.9.

And once you're on it, put the speed to work. Add tsc --noEmit to your pre-commit hook. Run it in CI on every PR. The whole point of a fast type-checker is that you stop rationing your checks — and the project I migrated to TypeScript 7 last week has already caught two type regressions that would have shipped.

One thing that helped me through the migration: I saved my updated tsconfig.json and the pre-commit hook script into my Snippet Ark library, so every new project starts from the same verified baseline instead of a half-remembered config from three jobs ago. If you keep your own collection of configs and commands, you know exactly what I mean — what's the one migration command or config you keep retyping on every new project? Save it somewhere better than a random GitHub gist.