TypeScript 7 is out - the native Go port, what changed, and what to watch

As of July 8th 2026, TypeScript 7.0 is generally available.

This is the release we have been tracking for over a year. The compiler and language service have been ported to Go, codename Corsa, and Microsoft is careful to call it a port and not a rewrite. Type-checking semantics from the 6.x line carry over on purpose. What you get is roughly a 10x speedup, parallel type-checking, a set of stricter defaults, and a batch of legacy options that are now hard errors.

There is one big caveat you need to know about before you upgrade a real project. TypeScript 7.0 ships without a public compiler API. If your stack depends on Vue, MDX, Astro, Svelte, or Angular templates, you cannot use TypeScript 7 yet. More on that below.

A port, not a rewrite

The new codebase mirrors the structure of the old one. Ryan Cavanaugh, who leads TypeScript engineering, explained the choice of Go in the "Why Go?" discussion: the goal was to keep the new codebase compatible with the JavaScript original both semantically and structurally, so that a port could realistically ship in a year instead of the multi-year effort a Rust rewrite would have required.

That framing matters. If you were expecting new type-system features to land with the Go port, that is not what this release is. The type checker behaves the same. The wins are speed, parallelism, and cleanup.

The port lives in a staging repo at github.com/microsoft/typescript-go. Microsoft has stated the repo will eventually be folded back into microsoft/TypeScript.

Roughly 10x faster

Here are Microsoft's reported numbers for full builds compared against TypeScript 6.0:

• 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)

Editor "open a file with errors" latency improved around 13x (17.5s → 1.3s). Visual Studio project load is roughly 8x faster.

Microsoft consistently uses "often about" and "typically 8x-12x" when framing these gains, and you should keep those hedges in mind. Independent testing on type-heavy codebases (Effect, drizzle-orm) lands closer to 3.9x-7.3x. And if your pipeline is I/O bound in CI, the end-to-end improvement can be closer to 28%. The compiler is dramatically faster, but the compiler is not always the bottleneck.

First-class parallelism

Parallel type-checking is now a real flag, not a benchmark. Three new options shipped:

# Run 4 type-checker workers (this is the default)
tsc --checkers 4
 
# Run 4 parallel project-reference builds
tsc --build --builders 4
 
# Turn everything off - useful for debugging
tsc --singleThreaded

Both --checkers and --builders are labeled experimental. In a monorepo with project references you can combine them - --checkers 4 --builders 4 runs up to 16 concurrent type-checkers.

Cranking --checkers 8 on the VS Code benchmark reaches a 16.7x speedup over TypeScript 6. Diminishing returns kick in above your physical core count, so this is not a "bigger number is better" flag.

Output stays deterministic. Type ordering under parallel workers is guaranteed by stableTypeOrdering, which is on by default and cannot be turned off.

New tsconfig defaults

Several defaults changed. The intent is to match how modern projects actually configure themselves, which means many tsconfig.json files can shrink significantly after upgrade.

{
  "compilerOptions": {
    "strict": true, // was false
    "module": "esnext", // was commonjs
    "target": "<current stable ECMAScript>", // was es5
    "types": [], // was ["*"] - no more auto-loading @types
    "rootDir": "./",
    "noUncheckedSideEffectImports": true,
    "stableTypeOrdering": true, // cannot be disabled
    "libReplacement": false,
  },
}

The types change is the one most likely to catch you. Previously a missing types array meant "load every @types/* package I can see." In TypeScript 7 an empty array means empty. If you actually want the old behavior back, you have to opt in:

{
  "compilerOptions": {
    "types": ["*"],
  },
}

Removed as hard errors

A long tail of legacy options are gone. These are not deprecation warnings - the compiler refuses to build if it sees them:

• target: "es5" and downlevelIteration
• module: "amd" | "umd" | "systemjs" | "none"
• moduleResolution: "node" | "node10" | "classic"
• baseUrl (use paths instead)
• Setting esModuleInterop or allowSyntheticDefaultImports to false
• alwaysStrict: false
• The module keyword inside namespace declarations
• assert on import statements - you must use with (the import attributes syntax)

The two most likely to bite modern codebases are baseUrl → paths and assert → with:

// ❌ TS 7 rejects this
import data from './data.json' assert { type: 'json' }
 
// ✅ Use import attributes
import data from './data.json' with { type: 'json' }

If you have a shared tsconfig.base.json in a monorepo, that is the place to start when auditing.

The Language Service moved to LSP

The editor tooling now speaks the Language Server Protocol directly. This is a bigger architectural shift than it sounds. It is what drives the roughly 8x Visual Studio project-load improvement, and it enables things like instant project-wide error listings and more advanced refactorings across editors that were previously VS Code-only.

Practically, editor extensions that talked to the old TSServer protocol will need to migrate.

The API is not shipping in 7.0

This is the caveat that matters for most people reading this.

TypeScript 7.0 does not ship with a public compiler API. Microsoft has stated 7.1 will introduce a new (and different) API, and until then any tool that consumes the programmatic TypeScript API cannot run on TypeScript 7.

That is a longer list than it sounds:

• Vue and Volar
• Astro
• Svelte
• MDX
• Angular template type-checking

If your framework's language tooling is on that list, you cannot upgrade to TypeScript 7 yet. To smooth the transition, Microsoft ships a compatibility package:

[object Object]

This installs a tsc6 binary and re-exports the TypeScript 6.0 API, so you can run tools that need the old API alongside TypeScript 7 for command-line type-checking. It is a bridge, not a permanent home. Framework maintainers are actively working on the migration and TypeScript 7.1 is where the ecosystem is expected to land.

TypeScript 6 is the last JS-based release

TypeScript 6.0 shipped in March 2026 and is the final release built on the JavaScript codebase. There is no planned 6.1. The 6.0.x line will only get rare patches for security, high-severity regressions, or 6-to-7 compatibility. Everything else moves to the Go implementation.

If you have been holding out for one more JavaScript-based release, this is your signal that it is not coming.

Should you upgrade?

For most application codebases, yes - with two checks:

1. Does anything in your build depend on the programmatic TypeScript API? Vue, Astro, Svelte, MDX, Angular templates are the common hits. If yes, stay on 6.0 and wait for 7.1, or use @typescript/typescript6 side-by-side.
2. Audit your tsconfig.json for the removed options. baseUrl, assert on imports, and disabled esModuleInterop are the three most likely to fail.

If neither of those bites, the speed win alone is worth the upgrade. Editor responsiveness on large codebases is where you will feel it first - the "open a file with errors" latency going from 17 seconds to 1 second is a different experience.

The full release announcement is on the TypeScript DevBlog. The port itself and its issue tracker are at microsoft/typescript-go.