TypeScript 7 Goes Native: What Breaks on Upgrade

#javascript #react #webdev #typescript

# TypeScript 7 Goes Native: What Breaks on Upgrade

TypeScript 7 (the release everyone's been calling Project Corsa) is not a normal version bump. The compiler and language service got rewritten from JavaScript into Go, and that rewrite is fast enough to change how you think about monorepo build times. It also breaks a chunk of your toolchain on the way in. Here's what actually changes, what actually breaks, and how to migrate without getting surprised mid sprint.

The honest speed numbers

Everyone's throwing around "faster" for the native compiler, so let's put real numbers next to it. Microsoft benchmarked the new Go based compiler (nicknamed tsgo) against the legacy JS tsc on full builds across a handful of real repos:

Project	Legacy `tsc`	Native `tsgo`	Speedup
sentry	133.08s	16.25s	~8.2x
vscode	89.11s	8.74s	~10.2x
typeorm	15.80s	1.06s	~14.9x
playwright	9.30s	1.24s	~7.5x

That's a 7.5x to 10.2x range depending on codebase shape, and it holds up across wildly different project sizes. If your CI pipeline spends real minutes on type checking, this alone is worth budgeting time for.

The catch: this is tsgo running full builds. Your editor's live language service (autocomplete, inline errors, go to definition) is a separate binary, and it inherits the same architecture, meaning the "typing lag" complaint a lot of large monorepos have quietly filed against TypeScript for years might finally be solved too.

What actually breaks

Here's the part nobody's cover post mentions clearly enough: Corsa does not support the old Strada API. Strada is the plugin surface the legacy tsc exposed for tooling, and a lot of your daily setup depends on it without you ever noticing.

Concretely, that means:

Linters and formatters built against the old compiler API can misbehave or fail outright until they ship a Corsa compatible build.
IDE extensions that hook into tsserver directly (not through the standard language service protocol) may break.
Some relaxed JSDoc type checking behaviors from the legacy compiler are gone. If your codebase leans on loosely typed JSDoc annotations instead of real .ts types, expect new errors to surface.

The migration guidance from the TypeScript team is refreshingly simple: run typescript and @typescript/native-preview side by side during the transition. Don't rip out the old compiler the day you install the new one. Keep both in your dependency tree, point CI at tsgo first as a canary, and only flip your default once the errors settle.

The flag changes you cannot ignore

TypeScript 6 quietly became the last release built on the legacy JavaScript codebase, meaning only patch releases (security and high severity compatibility fixes) will land on it going forward. Everything net new happens on the Go port from here.

Along with the native rewrite, several defaults formalized as breaking changes between 6 and 7:

strict mode is on by default now. If your tsconfig.json was relying on the old permissive default, this alone can surface a wave of new errors.
target defaults to the latest stable ECMAScript version instead of an old fixed baseline.
The es5 target option is removed. If you're still shipping to genuinely ancient runtimes, pin your target explicitly before upgrading.
baseUrl and moduleResolution: node10 are removed. Anything relying on the old Node resolution algorithm needs to move to bundler or node16/nodenext resolution.

None of these are surprises in isolation. Together, on the same release, they're the kind of thing that turns a routine dependency bump into an afternoon. If you're running TypeScript across a production Next.js codebase, I go deeper into what an upgrade like this means for AI product builds on Next.js separately.

A practical migration checklist

Before you flip your default compiler over, run through this in order:

Add @typescript/native-preview alongside your existing typescript dependency. Do not remove the old one yet.
Point one CI job at tsgo as a canary build, keep your real gate on the legacy compiler.
Audit every linter, formatter, and editor extension in your toolchain for a Corsa compatible release. If one hasn't shipped yet, that's your actual blocker, not the compiler itself.
Set strict: true explicitly in tsconfig.json if it isn't already, and fix what surfaces on your own schedule instead of on upgrade day.
Search your config for baseUrl, moduleResolution: "node10", and target: "es5". Replace before you touch the compiler swap.
Once your canary CI job is green for a week, flip the default and drop the legacy compiler from your dependency tree.

Three things to verify right now

Run these before you plan a migration window:

npx tsc --version

Confirms which compiler generation your project is actually pinned to today.

grep -E "baseUrl|node10|es5" tsconfig.json

Catches every removed option in one pass instead of finding them one build error at a time.

npm ls typescript @typescript/native-preview 2>/dev/null

Shows whether you're already running both compilers side by side, which is the state you want before cutting over.

If you want a deeper look at building on Next.js with a modern TypeScript setup, I cover it in more detail on my site.

If you want this wired up on your own site end to end, that is exactly the kind of work I take on.

Drop a comment if your setup looks different. Curious how many people are already running the native preview in production versus still waiting for their toolchain to catch up.