7 min read

TypeScript 7.0 Is GA: What the Go-Native Compiler Actually Changes for Frontend Engineers

If your CI still burns seven minutes type-checking a mid-sized React app, that number is now a choice. TypeScript 7.0 went GA on July 8, 2026, and the headline isn't a new utility type or a smarter infer — it's that tsc is no longer written in TypeScript. The compiler was ported to Go (the project you saw as "Corsa" and the tsgo binary during the preview), and the TypeScript 7.0 Go compiler delivers the ~10x type-check speedup Microsoft promised. The catch: to get it, the team also flipped a pile of long-deprecated config defaults into hard errors. This is the most disruptive TS release in years, and it's disruptive on purpose.

The 10x is real, and it's not a microbenchmark

The original Sentry number Microsoft published was a full build going from 72.81s on 5.8 to 6.76s on the native compiler — type-checking alone dropping 63.26s to 5.88s. That held up across the GA benchmark set at default settings:

  • 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)

Memory on the VS Code repo fell from 5.2GB to 4.2GB (−18%), and — the number that actually matters day to day — editor latency opening a file with errors went from ~17.5s to under 1.3s. Tune the checker pool and it goes further: VS Code with --checkers 8 on a beefy runner hit 7.51s, a 16.7x win. Slack has reported CI type-checking falling from ~7.5 minutes to 1.25.

Why so much? Two structural reasons. Go compiles to native code with real threads, so the compiler uses shared-memory multithreading instead of fighting Node's single-threaded event loop — the old tsc couldn't parallelize the checker at all. And the port swapped in a Go version of Parcel's cross-platform file watcher, so watch-mode incremental checks aren't paying the Node fs-watch tax anymore. This isn't a rewrite that got clever with algorithms; it's the same type system on a runtime that can actually use your cores.

powershell
# Try it before you commit to the migration — the preview package still works npm install -D @typescript/native-preview npx tsgo -p . --noEmit --extendedDiagnostics

The breaking changes will bite before the speedups help

Here's the part the "10x faster!" headlines skip. TypeScript 7.0 changes defaults and promotes a batch of deprecated options from warnings to hard errors. If you've been ignoring the 6.x deprecation warnings, GA day is when they stop being ignorable.

New defaults that can silently change behavior:

  • strict: true — no longer configurable off by omission
  • module defaults to esnext
  • types defaults to [] — this one is the sneaky one; TS no longer auto-includes every @types/* package in node_modules
  • rootDir defaults to ./

Options that are now hard errors:

  • target: es5, downlevelIteration, baseUrl
  • moduleResolution: node (use bundler, node16, or nodenext)
  • module: amd | umd | systemjs | none
  • esModuleInterop and allowSyntheticDefaultImports can no longer be false

The types: [] change deserves a callout because it fails in the least obvious way: your app compiles, then suddenly describe, it, process, or NodeJS.Timeout are unresolved because Jest, Node, or Vite's client types are no longer implicitly global. The fix is to say what you actually depend on:

javascript
// tsconfig.json — be explicit about ambient types now { "compilerOptions": { "types": ["node", "vite/client", "vitest/globals"] } }

There's also a genuinely subtle semantic break: template literal types now treat full Unicode code points as single units instead of splitting UTF-16 surrogate pairs. If you have string-manipulation types operating on emoji or non-BMP characters, they can resolve differently. Niche, but if it's you, it's a silent miscompile of your types, not a loud error.

The tooling gap is the real blocker, not your app code

For plain application code, migration is mostly a tsconfig reconciliation — Vite and webpack type-check through tsc with no compiler-API dependency, so they work immediately. The problem is everything that reaches into the compiler programmatically. The Go port doesn't expose the old Node-based compiler API yet (that's slated for a new, different API in 7.1), so anything built on it is stranded on GA day:

  • typescript-eslint — unless you route it through the @typescript/typescript6 shim
  • Vue (Volar template tooling), Angular template type-checking
  • Svelte, Astro, MDX — embedded-language support all needs the programmatic API

Microsoft's bridge is the @typescript/typescript6 package: it re-exports the entire 6.0 API and ships a tsc6 binary, so API-dependent tools keep running on the old compiler while your tsc runs native. That's the pattern for a mixed setup:

powershell
# Run native tsc for fast checks, keep the 6.x API alive for tooling that needs it npm install -D typescript @typescript/typescript6 npx tsc --noEmit # native, fast # typescript-eslint / build plugins resolve the compiler API from typescript6

If you're an Angular shop, the sanctioned interim setup is TS 7 for CLI checks (tsc) and TS 6.0 for the editor and template type-checking until Volar/Angular land on the 7.1 API. Frameworks like Vue and Svelte are moving, but check your specific plugin's release notes before you bump typescript to latest — latest now resolves to 7.0, so an unpinned upgrade can break your editor experience without touching a line of your code.

A migration playbook that won't ruin your afternoon

Do the prep work while still on 6.x, where the deprecated flags warn instead of erroring. That turns the actual version bump into a non-event.

  1. Clean tsconfig on 6.x first. Remove es5 targets, moduleResolution: node, baseUrl, and the interop falses while they're still warnings.
  2. Install and check. npm install -D typescript then tsc --noEmit. Triage config errors before code errors — most of your "errors" will be the new defaults, not real type regressions.
  3. Restore ambient types deliberately. Add the types array with exactly the @types packages you rely on. Don't shotgun it back to old behavior; the explicit list is better hygiene anyway.
  4. Add the shim if tooling needs it. @typescript/typescript6 for typescript-eslint or any custom compiler-API scripts.
  5. Tune CI. Try --checkers N on your runner core count; --builders for parallel project references in a monorepo; --singleThreaded when you need deterministic output to debug.
  6. Diff your build output. Emit is complete in the port, but build a before/after and diff it once so you trust it.

The whole thing is usually a half-day for an app, and most of that half-day is arguing with types: [].

What this actually signals

Zoom out and TS 7 is one data point in a pattern that defined frontend tooling this year: the JavaScript-tooling-written-in-JavaScript era is ending. Vite unified on Rolldown (Rust). The React Compiler got ported to Rust. esbuild and swc normalized native bundling years ago, and now the type-checker — the last big holdout, the tool you wait on most — went native too. The bottleneck was never the type system's cleverness; it was running a CPU-bound workload on a single-threaded VM.

The practical lesson for how you work: your type-checker is no longer the thing you optimize around. A lot of accumulated workflow — sharding CI type-checks across jobs, skipLibCheck as a crutch, splitting projects mainly to keep tsc bearable, treating a slow editor as the cost of a big monorepo — was scar tissue around a slow compiler. That scar tissue is now removable. The teams that get the most out of TS 7 won't be the ones who bump the version fastest; they'll be the ones who go back and delete the workarounds they built when checking was slow, and let their tooling assume type-checking is cheap. Fast tools don't just save minutes — they change which architectures are worth having.