TypeScript 7 and 7.1: what changes with the native compiler

TypeScript 7.0 shipped in August 2026, and it’s the most significant release in the project’s history — but not because of new syntax. The compiler itself was rewritten from scratch in Go, replacing the TypeScript-compiles-itself codebase that had existed for over a decade. The headline isn’t “you can now write code you couldn’t before” — it’s “the exact same code now type-checks 8-10x faster.”

Why rewrite the compiler in Go

The old tsc is written in TypeScript and runs on Node.js: single-threaded, with the overhead of the JavaScript VM and a general-purpose garbage collector. The team, led by Anders Hejlsberg, ported the entire compiler logic to Go, keeping the internal structure as close to the original as possible. The project started in 2025 under the codename “Corsa” and shipped as a preview under the @typescript/native-preview package (the binary was called tsgo). With the 7.0 RC, that native compiler became the standard tsc inside the typescript package itself.

Two concrete advantages of Go over JavaScript for this use case: compiled native code instead of interpreted/JIT execution, and real shared-memory parallelism — something Node.js’s single-threaded model can’t offer without the cost of inter-process serialization.

The numbers: 8-12x faster on real projects

These aren’t synthetic benchmarks. They’re full builds of well-known open source projects, comparing TypeScript 6 with TypeScript 7:

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

Memory usage also dropped, between 6% and 26% depending on the project. Opening files in the editor is up to 13x faster, and Microsoft reports concrete production impact: Slack cut CI type-checking from 7.5 to 1.25 minutes, Canva went from 58 to 4.8 seconds to show the first error in the editor.

The breaking changes: new defaults, not just speed

This is the part that needs attention before upgrading an existing project. TypeScript 7.0 changes several long-standing defaults:

• strict: true by default (previously false)
• module: esnext by default
• noUncheckedSideEffectImports: true by default
• types: [] by default — every @types package in node_modules is no longer auto-included
• rootDir now defaults to the project root

Some legacy options have also been removed entirely: target: es5, downlevelIteration, the amd/umd/systemjs module systems, and baseUrl. If your tsconfig.json relies on any of these, moving to 7.0 means an actual migration, not just a version bump.

There’s also a subtler breaking change in how template literals handle Unicode: emoji and multi-byte characters are now treated as single units instead of UTF-16 surrogate pairs. "😀abc" now correctly splits into ["😀", "abc"], instead of splitting the emoji in half.

What’s still missing: the programmatic API

The most relevant limitation of this first native release: TypeScript 7.0 doesn’t yet expose a stable programmatic API. That’s a real problem for anything that leans on the compiler to analyze non-.ts code — Vue (Volar), Svelte, Angular templates, and yes, .astro files like the ones powering this very blog. Those tools can’t migrate to 7.0 yet and stay on the classic JavaScript compiler for now.

For anyone who needs both compilers to coexist during the transition, Microsoft suggests this pattern in package.json:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

TypeScript 7.1: what’s landing in November 2026

As of this writing, 7.1 hasn’t shipped yet: beta is planned for October 6, 2026, with stable targeted for November 24, 2026. From the team’s published iteration plan, the main points are:

• API stabilization: the Content Mapper API, Emit API, and Language Service API become stable — this is exactly the missing piece that unblocks migration for tools processing .vue, .astro, and similar files.
• Support for type on import attributes and source phase imports.
• es2026 as a new option for lib and target.
• lib.d.ts updates for new iterator methods and DOM APIs, including Promise.allKeyed and Promise.allSettledKeyed.
• Further performance work: faster union type construction, quicker narrowing on assignments and equality checks.

In short: 7.0 is the infrastructure leap (same language, new engine), 7.1 is the release that completes the surrounding ecosystem — the missing API, plus some alignment with newer JavaScript features.

Should you upgrade now?

If your project is plain TypeScript/JavaScript with no dependency on tools that rely on the compiler’s programmatic API, the jump to 7.0 is already worth it purely for build times — especially on a large codebase or in CI. But if your stack includes frameworks that process non-standard files (Vue, Astro, Svelte) through plugins built on the compiler API, it’s worth waiting for 7.1 and the stabilized Language Service API before forcing the migration.

Either way, it’s worth reviewing your tsconfig.json before upgrading: the new defaults (strict, module: esnext, types: []) can surface errors that stayed silent under TypeScript 6.

If you often work with typed configuration objects, you might also like the article on the satisfies operator, another language feature built for similar precise-inference cases.