TypeScript 7.0 goes native in Go, TS 6.0 breaks defaults

I’ve watched monorepo type-checks crawl past the 2-minute mark and quietly train teams to ignore errors.

TypeScript 6.0 and 7.0 aim straight at that pain. 6.0 changes defaults and removes old escape hatches, 7.0 replaces the JS compiler with a Go binary called tsgo, and the whole ecosystem has to adjust.

What’s actually shipping: tsgo side-by-side with tsc

Here’s the thing people miss on the first read.

You probably will not “upgrade to 7.0” in one clean step. In most teams, you’ll run tsc for anything that still needs the old TypeScript API, and you’ll run tsgo for fast type-checking where it fits.

• TypeScript 7.0 is a compiler rewrite in Go: Microsoft calls it Project Corsa, and they ship it today as a native preview you install from npm. You run it with tsgo, not tsc.
• The speedups look real, but they’re not magic: Microsoft reports full-build improvements in the 7.5x to 10x range on large codebases, with published examples like Sentry dropping from 133 seconds to 16 seconds and VS Code dropping from 89 seconds to 9 seconds. Cite that when you sell this internally.
• Parallelism matters more than the language choice: The native compiler can do shared-memory parallel work. On big project-reference graphs, that’s where you feel it, fans spinning down, CI minutes shrinking.

Editor changes: LSP replaces the old TS server model

This bit me when I tried a preview language service in a real repo.

The compiler felt faster, then my editor started acting “off” in tiny ways: stale diagnostics, missing quick fixes, imports that worked in one file but not another. That’s the usual early-language-server tax, and it’s why you should treat editor rollout separately from CI rollout.

• TypeScript 7.0 language service speaks LSP: That should make non-VS Code editor integrations less weird over time, but it also means new failure modes and new extension versioning to manage.
• Do the editor trial on one team first: Pin the VS Code “native preview” extension for that group, keep everyone else on the normal TypeScript extension, and compare diagnostics for a week.

If your editor and CI disagree, developers will trust the editor. Fix that mismatch first.

TypeScript 6.0: the “bridge” release that still breaks you

Expect churn.

TypeScript 6.0 exists to set the ecosystem up for 7.0. It does that by changing defaults and removing compatibility options that kept ancient targets alive. Some folks will call this “cleanup.” I call it “a Tuesday that ruins your backlog.”

• --strict flips on by default: If you have a half-strict codebase, start enabling strict now and fix errors in slices. Do not wait for the major bump and hope for the best.
• The default target moves forward: ES5 stops being the silent default. If you still ship ES5 for real users, you likely stay on TypeScript 5.x until your support matrix changes.
• Module resolution gets narrower: If you still use moduleResolution “node” or “node10,” plan a switch to nodenext (Node projects) or bundler (Vite/webpack style builds). This change shows up as “why did my imports break” tickets.
• baseUrl and rootDir get less forgiving: The breakage here looks like output paths shifting or build artifacts landing in the wrong folder. It feels dumb until you lose an hour chasing it.

What tsgo still does not do (and why that matters)

Speed only helps if it fits your pipeline.

Right now, the native compiler preview does not fully replace the JavaScript emit story. If your build relies on TypeScript to downlevel to older targets, you need to read the limitations twice and test your exact output.

• Emit has gaps: Microsoft documents that downlevel emit only goes back to around ES2021 today, and decorator emit support is not there yet. If you use Babel or esbuild for emit already, you might not care.
• Watch mode can regress: In some repos, the old compiler’s watch mode stays more efficient. You can still run tsgo –incremental and wrap it with your process watcher, but measure it.
• The old TypeScript API (Strada) does not carry over: Tooling that imports typescript as a library will not just “work” on 7.0. Plan for a dual-install period.

A migration plan that won’t wreck your week

Go slow.

I do not trust “known issues: none” from any project, especially not in a rewrite. If this repo pays salaries, test it twice. If it’s a dev sandbox, just yolo it on Friday and learn what breaks.

• Step 1, add tsgo without replacing anything: Install @typescript/native-preview and run npx tsgo –build path/to/tsconfig.json –extendedDiagnostics in CI as a non-blocking job.
• Step 2, keep tsc for tooling: If ESLint parsers, codegen, or custom scripts import typescript, keep your stable TypeScript version installed and keep those jobs on tsc.
• Step 3, trial TS 6 strictness now: Turn on strict in a branch, fix the top 20 errors, merge, repeat. The teams that treat strictness as a one-time event usually regret it.
• Step 4, decide where speed matters: Use tsgo first on CI type-checking for the biggest package graph. Leave everything else alone until you see a clean week of green builds.

Ignore the GitHub commit count. It’s a vanity metric. Run the compiler on your repo and measure wall-clock time.

JavaScript + JSDoc users: expect new errors

This one will surprise people.

If you have a big JavaScript codebase that relies on JSDoc for checking, the native rewrite tightens behavior. Microsoft calls out dropped recognition for tags like @enum and @constructor, and it removes some “relaxed” assumptions. That usually means you wake up to a pile of new red squiggles.

• Run the preview against your JS packages first: Do it before you touch TS 6 defaults, or you won’t know which change caused which error.
• Plan small rewrites: Replace fragile JSDoc patterns with TypeScript files in the hotspots where the errors block work.

So should you move?

Depends.

If your type-checking already finishes in 8 seconds, you can probably wait and let the ecosystem settle. If your CI spends 6 minutes in TypeScript, you should start testing tsgo now, because the performance upside looks worth the hassle. Other stuff in this release: dependency bumps, some image updates, the usual. There’s probably a better way to stage the editor rollout, but…