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…

What the Go rewrite means for your build pipeline

The TypeScript team rewrote the compiler in Go for one reason: speed. The native compiler targets 10x faster type checking. For a 500-file project, that might mean going from 12 seconds to 1.2 seconds. 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. The other half is what breaks.

• 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 before upgrading. The migration path for plugins is still being defined.
• Language server protocol: The new compiler includes a new language server. VS Code, Neovim, and other editors will need updated TypeScript extensions. Expect a transition period where the old and new language servers coexist. Pin your editor extension version during migration.
• CI implications: If your CI caches node_modules and relies on npx tsc, the Go binary changes how the compiler is distributed. It ships as a platform-specific binary, not a Node.js script. Docker images that run tsc need to include 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. It introduces the breaking changes gradually.

1. Upgrade to TS 6.0 first: Fix any new strict-mode errors. TS 6.0 changes some default compiler options — exactOptionalPropertyTypes becomes more strict, and some previously-allowed patterns in declaration files now error. Run your full test suite.
2. Audit your tsconfig: The Go compiler does not support every obscure tsconfig option at launch. Check the compatibility table in the release notes. If you use composite projects, verify that project references still resolve correctly.
3. Test editor integration: Open your largest file in VS Code with the new language server. Check that autocomplete, go-to-definition, and rename-symbol work. Report regressions to the TypeScript GitHub — the team is actively fixing these during the preview period.
4. Benchmark before and after: Run tsc –diagnostics on your project with both compilers. Compare check time, memory usage, and total time. If the new compiler is not faster for your project, file an issue — the team wants these reports.
5. Upgrade CI last: Keep the JS-based compiler in CI until you have confirmed the Go compiler produces identical output for your project. Use tsc –noEmit with both and diff the diagnostics.

Should you wait or adopt early?

If you maintain a library published to npm: wait. The declaration emit must be identical between the old and new compilers before you switch. Any difference in .d.ts output means your consumers see different types depending on their compiler version.

If you maintain a private application: try the 7.0 preview now. The speed improvement changes how you work. Faster type checking means you actually run tsc before committing instead of waiting for CI. That alone reduces bugs.

If you run a monorepo with 50+ packages: you are the target audience. The Go compiler was built for you. Test it aggressively, report issues, and plan for a Q3 2026 migration once the ecosystem catches up.

Practical code: trying tsgo and TS 6.0 today

Here are the commands and configurations you will actually run during migration.

Install and run the native preview

# Install the native TypeScript preview (Go-based compiler)
npm install @typescript/native-preview

# Run tsgo on your project with diagnostics
npx tsgo --build tsconfig.json --extendedDiagnostics

# Compare with the classic compiler
npx tsc --noEmit --extendedDiagnostics

# Run both and compare wall-clock time
time npx tsgo --noEmit && echo "tsgo done"
time npx tsc --noEmit && echo "tsc done"

Prepare your tsconfig for TS 6.0 strict defaults

// tsconfig.json — enable strict settings before TS 6.0 forces them
{
  "compilerOptions": {
    "strict": true,
    "moduleResolution": "nodenext",
    "module": "nodenext",
    "target": "ES2022",
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true,
    "verbatimModuleSyntax": true
  }
}

CI script: run both compilers in parallel

# .github/workflows/typecheck.yml
name: TypeCheck (tsc + tsgo)
on: [push, pull_request]
jobs:
  typecheck:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        compiler: [tsc, tsgo]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm ci
      - run: npm install @typescript/native-preview
        if: matrix.compiler == 'tsgo'
      - run: npx ${{ matrix.compiler }} --noEmit
        name: Type-check with ${{ matrix.compiler }}

Official resources

These links will help you track the migration and understand what is changing under the hood:

• TypeScript Release Notes — official changelog for every TypeScript version including 6.0 beta changes
• TypeScript Native Port tracking issue (GitHub #58243) — the main tracking issue for the Go rewrite with status updates from the TypeScript team

Keep Reading

• Go Release History
• TypeScript Release History
• Speed Up TypeScript Build Times (TS 5.7/5.8): Fix Your Graph
• Go 1.25.6 release notes: the boring patch that is not boring

Frequently Asked Questions

• Is TypeScript 7.0 a rewrite in Go? Yes. The TypeScript compiler (tsgo) is being rewritten from JavaScript to Go, targeting 10x faster type-checking and build times. TypeScript 6.0 ships first as a bridge release that aligns the JS compiler with what tsgo expects, while 7.0 makes tsgo the primary compiler. Both will be available side by side during transition.
• Will TypeScript 7.0 break my existing code? Not directly — tsgo aims for identical type-checking behavior. But TypeScript 6.0 (the bridge release) does break some defaults, and you’ll need to go through 6.0 first. The real risk is in build tooling: plugins, custom transformers, and anything relying on the TypeScript compiler API will need updates since Go doesn’t expose the same JavaScript internals.
• Should I wait for TypeScript 7.0 or upgrade to 6.0 now? Upgrade to 6.0 as soon as it’s stable. TS 6.0 is the mandatory stepping stone — it surfaces the breaking changes you’ll need to fix anyway. Getting 6.0 working in your CI now means 7.0 adoption becomes a compiler swap, not a debugging marathon. Early adopters who skip 6.0 will have a harder time.
• What does the Go rewrite mean for build pipelines and IDE support? Build times drop dramatically — expect 5-10x improvement for type checking on large codebases. LSP replaces the old TS server model for editor integration. The catch: custom transformer plugins and anything using the programmatic TypeScript API needs rewriting. If your build pipeline just runs tsc, the migration is straightforward.

Related Reading

• Speed Up TypeScript Build Times — Fix your dependency graph
• Python 3.12 vs 3.13 vs 3.14 Comparison — Which end-of-life/">Python version to use in production
• How to Add Version Health Badges — Show version status in your README