TypeScript 7's Go Compiler Just Landed in VS Code: Here's What You're Actually Getting

TypeScript 7's Go Compiler Just Landed in VS Code: Here's What You're Actually Getting

TypeScript 7 has been the most-discussed unreleased tooling change in the JavaScript ecosystem for the past year. This week, it got real in a way you can feel: VS Code 1.107 shipped experimental support for the TypeScript 7 native language server, and the @typescript/native-preview package is available on npm for teams who want to try the Go-based compiler today.

The performance numbers have been floating around for months. The VS Code codebase: 77 seconds type-check time on the current compiler, 7.5 seconds on the Go port. Playwright: 11.1 seconds down to 1.1 seconds. A 10x improvement isn't hype when the benchmarks are this consistent across real-world codebases.

But speed isn't the only story. The architecture change has real implications for how type-checking works — and the TypeScript 6.0 cleanup from March was explicitly designed to make this transition possible.

---

Why the Compiler Is Being Rewritten

The JavaScript-based TypeScript compiler has been single-threaded since 2012. The V8 isolate model that made it embeddable everywhere also made true parallelism impossible. As projects grew — monorepos with dozens of packages, Next.js apps with hundreds of route files — that ceiling became painful.

The Go rewrite (project Corsa) uses goroutines and shared memory. When the type-checker processes a large project, it can parallelize across files in a way the JS compiler never could. That's where most of the 10x gain comes from.

The tradeoff: the Go compiler uses a different type ordering algorithm — deterministic, based on object content rather than declaration encounter order. This doesn't change correctness for most code, but it can surface latent type errors that the old compiler happened to resolve in your favor.

---

How to Try It Today

The preview package is on npm:

npm install -D @typescript/native-preview

For VS Code, install the TypeScript 7 Native Language Service Preview extension and switch your workspace to use it. You'll get fast type-checking in the editor, plus errors that match what TS 7 will actually produce.

Before you switch, run --stableTypeOrdering on your existing TS 6.0 setup:

npx tsc --stableTypeOrdering --noEmit

This flag previews TS 7.0's type ordering without changing your compiler. Fix whatever it surfaces, then try the native preview. If both pass cleanly, your 7.0 upgrade is going to be boring — and that's the goal.

---

What TypeScript 6.0 Changed (and Why It Matters Now)

TypeScript 6.0 wasn't primarily a feature release. The big structural move was **changing the defaults across the board**:

| Option | Old default | New default | |---|---|---| | strict | false | true | | module | commonjs | esnext | | target | es5 | es2025 | | types | all @types/* | [] | | noUncheckedSideEffectImports | false | true |

If your tsconfig explicitly pins these options, this is mostly noise. But if you've inherited a project with a thin tsconfig that leaned on TS's old defaults, you need to audit it before upgrading.

The types: [] change is the one that bites teams hardest. If you're on Node.js and your tsconfig didn't explicitly include node types, TS 6.0 stops seeing Node.js globals. Your build breaks with Cannot find name 'process'. The fix:

{
  "compilerOptions": {
    "types": ["node"]
  }
}

Side-effect imports are also validated now:

// TS 6.0+: errors if this path cannot be resolved
import './polyfills';

Previously TypeScript silently ignored resolution failures on side-effect imports. Now it errors. Good for catching typos; annoying if you have unconventional polyfill setups or CSS module imports wired through a custom resolver.

AMD, UMD, SystemJS, and --outFile are removed entirely. No compatibility shim. If you're still on those, you can't upgrade until you migrate your module system.

---

The Migration Path

Practically:

1. **Upgrade to TS 6.0 and triage every error.** Most are a tsconfig change or an explicit type annotation. Not a full migration project. 2. **Add ignoreDeprecations set to "6.0"** in your tsconfig if you hit deprecation warnings you can't fix yet. This buys time but won't work in 7.0, so treat it as a deadline, not a permanent setting. 3. **Run --stableTypeOrdering once** to surface type-ordering-sensitive code before it becomes the compiler's default. 4. **Install @typescript/native-preview** on a separate CI step and run it against your full type-check. New errors that only appear there are bugs to file or fix before 7.0 GA.

The goal is to enter 7.0 GA with no outstanding deprecation warnings and a clean native-preview run. At that point the upgrade is a package swap.

---

Also in TS 6.0: Temporal API Types

TypeScript 6.0 shipped first-class types for the Temporal API, which hit Stage 4 in TC39. Available under esnext.temporal:

// Node.js 26+ with --experimental-temporal, or use a polyfill
const now = Temporal.Now.plainDateTimeISO();
const later = now.add({ hours: 2, minutes: 30 });
console.log(later.toString()); // 2026-06-19T14:30:00

Node.js 26 has experimental Temporal support, so this is usable today without a polyfill on the right runtime version. Not the main reason to upgrade — but a practical bonus when you do.

---

The Honest Take

The TypeScript 7 situation is unusual because the preview is good enough to validate against today, but not ready for production type-checking yet. The language server in VS Code 1.107 is experimental for a reason — there are edge cases the Go port is still working through.

Use the native preview as a **forward-compatibility check**, not your main compiler. A separate CI job running @typescript/native-preview gives you early warning without risk. If it passes, 7.0 GA will be smooth. If it surfaces new errors, you have time to fix them now.

The speed gains are real. Teams on large TypeScript monorepos have been waiting for this for years. The upgrade window is open, and the work is mostly what TypeScript 6.0 already flagged.