TypeScript 7.0 Goes Native in Go, TS 6.0 Breaks Defaults

Update (Feb 19, 2026): TypeScript 6.0 Beta officially dropped on Feb 11. Microsoft confirmed this is the last JavaScript-based release before the Go rewrite ships as TypeScript 7.0. Everything below still applies.

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

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. You run it with tsgo, not tsc.
• The speedups look real, but they're not magic: Microsoft reports 7.5x to 10x improvements. Sentry dropped from 133 seconds to 16 seconds. VS Code dropped from 89 seconds to 9 seconds.
• 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.

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.

• TypeScript 7.0 language service speaks LSP: Good for non-VS Code editors long-term, but new failure modes during transition.
• Do the editor trial on one team first: Pin the VS Code "native preview" extension, keep everyone else on the normal TypeScript extension, compare 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.

• --strict flips on by default: If you have a half-strict codebase, start enabling strict now and fix errors in slices.
• 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.
• Module resolution gets narrower: If you still use moduleResolution: "node" or "node10", plan a switch to nodenext or bundler.
• baseUrl and rootDir get less forgiving: Output paths can shift or build artifacts land in the wrong folder.

What tsgo Still Does Not Do

Speed only helps if it fits your pipeline.

• Emit has gaps: Downlevel emit only goes back to around ES2021. Decorator emit support is not there yet.
• Watch mode can regress: In some repos, the old compiler's watch mode stays more efficient.
• The old TypeScript API (Strada) does not carry over: Tooling that imports typescript as a library will not "work" on 7.0. Plan for a dual-install period.

A Migration Plan That Won't Wreck Your Week

Go slow. If this repo pays salaries, test it twice.

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.
2. Keep tsc for tooling: If ESLint parsers, codegen, or custom scripts import typescript, keep your stable version installed.
3. Trial TS 6 strictness now: Turn on strict in a branch, fix the top 20 errors, merge, repeat.
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.

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

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.

• Run the preview against your JS packages first, before you touch TS 6 defaults.
• Plan small rewrites: replace fragile JSDoc patterns with TypeScript files in the hotspots.

What the Go Rewrite Means for Your Build Pipeline

The TypeScript team rewrote the compiler in Go for one reason: speed. For a monorepo with 5,000 files, it means going from two-minute builds to something that feels interactive.

But speed is only half the story:

• Plugin ecosystem: TypeScript compiler plugins written in JavaScript will not work with the Go-based compiler out of the box. If you use ts-patch, custom transformers, or ttypescript, check compatibility.
• Language server protocol: VS Code, Neovim, and other editors will need updated TypeScript extensions. Pin your editor extension version during migration.
• CI implications: The Go binary changes distribution. Docker images that run tsc need the right architecture binary. Multi-platform CI runners might need separate cache keys.

Migration Checklist: TS 5.x to 6.0 to 7.0

Do not jump from 5.x to 7.0. TypeScript 6.0 is the bridge release.

1. Upgrade to TS 6.0 first: Fix strict-mode errors. Run your full test suite.
2. Audit your tsconfig: The Go compiler does not support every obscure tsconfig option at launch.
3. Test editor integration: Open your largest file with the new language server. Check autocomplete, go-to-definition, rename-symbol.
4. Benchmark before and after: Run tsc --diagnostics with both compilers. Compare check time and memory usage.
5. Upgrade CI last: Keep the JS-based compiler in CI until you've confirmed identical output.

Should You Wait or Adopt Early?

If you maintain a library published to npm: wait. The declaration emit must be identical before you switch.

If you maintain a private application: try the 7.0 preview now. Faster type checking means you actually run tsc before committing.

If you run a monorepo with 50+ packages: you are the target audience. Test aggressively, report issues, plan for Q3 2026.

FAQ

Is TypeScript 7.0 a rewrite in Go?
Yes. The compiler (tsgo) targets 10x faster type-checking. TS 6.0 ships first as a bridge release.

Will TypeScript 7.0 break my existing code?
Not directly, but TS 6.0 (the bridge release) does break some defaults. The real risk is in build tooling: plugins, custom transformers, and anything relying on the TypeScript compiler API.

Should I wait for TypeScript 7.0 or upgrade to 6.0 now?
Upgrade to 6.0 as soon as it's stable. It's the mandatory stepping stone. Getting 6.0 working now means 7.0 becomes a compiler swap, not a debugging marathon.

---

Originally published on ReleaseRun.