TypeScript 7.0: What the Go Port Changes for Builds, Defaults and Tooling

TypeScript 7.0 replaces the JavaScript compiler with a native Go port. This article covers the published speedups and their conditions, the breaking default changes, and which tools still depend on TypeScript 6.

A full type-check of the VS Code repository took 125.7 seconds with TypeScript 6 and 10.6 seconds with TypeScript 7, according to the team's own announcement. That is the headline, but for most teams the more important facts are in the fine print: new defaults that change what compiles, and a missing programmatic API that blocks several tools.

The question: what changed inside the compiler to produce those numbers, and what has to change in your repository before you can adopt it?

Background: from JavaScript to a native port

TypeScript 7.0 was announced on July 8, 2026 by Daniel Rosenwasser. It is a native port of the compiler written in Go, developed in the microsoft/typescript-go staging repository, whose README says it will be permanently archived in September 2026 now that development has moved back to the main TypeScript repository. Per the announcement, TypeScript 6.0 was the last JavaScript-based line; I confirmed from the README and announcement that 7.0 targets parity with 6.0 behavior, with documented intentional differences in a CHANGES.md file.

How it works: a faithful port with shared-memory parallelism

The announcement says the port keeps the structure and logic of the original codebase so results stay consistent with TypeScript 6. What is new is concurrency: shared-memory multithreading with parallel parsing, type-checking and emit. The type-checking parallelism is exposed through a --checkers option, with a default of 4 in the published benchmark. The editor experience is now built on the Language Server Protocol, and --watch mode was rebuilt on a file watcher ported from Parcel's @parcel/watcher.

Deep analysis: the published numbers and their conditions

The team's table compares full builds of TypeScript 6 and 7 with the default --checkers 4:

Codebase	TS 6	TS 7	Speedup
vscode	125.7 s	10.6 s	11.9x
sentry	139.8 s	15.7 s	8.9x
bluesky	24.3 s	2.8 s	8.7x
playwright	12.8 s	1.47 s	8.7x
tldraw	11.2 s	1.46 s	7.7x

With --checkers 8, vscode drops to 7.51 s (16.7x) and the others reach 10.6x to 12.1x. Peak aggregate memory fell 6 to 26 percent on the same projects (vscode: 5.2 GB to 4.2 GB), and time to first error in the editor for vscode fell from about 17.5 s to under 1.3 s. The announcement says the tests ran on the same machine but does not list hardware, so these are vendor figures I could not reproduce and cannot normalize to your CPU. Third-party outlets quote "up to 12x" or "about 10x", which is a rounding of the same data. Because speedup depends on core count and checker count, a laptop with fewer cores should expect less from the parallel part.

Breaking changes you will actually hit

New defaults per the announcement: strict is on, module is esnext, noUncheckedSideEffectImports is on, libReplacement is off, rootDir is ./ and types is []. Removed options now error: target: es5, downlevelIteration, node/node10 and classic module resolution, AMD, UMD, SystemJS and none module kinds, baseUrl, and setting esModuleInterop or alwaysStrict to false. JavaScript analysis was reworked to match .ts, so JSDoc patterns such as Closure-style function types stop working. Of these, an empty default types array is the likeliest silent breaker: projects that relied on automatic inclusion of every @types package must list them.

Comparison with alternatives

Approach	Type checks?	Trade-off
TypeScript 7 `tsc`	Yes, full parity target with 6.0	No programmatic API until the expected 7.1; stricter defaults
TypeScript 6 (`@typescript/typescript6`, `tsc6`)	Yes	Slower; still the dependency for plugin-based tooling
Transpile-only tools (esbuild, swc, Babel)	No	Fast, but you still need a type-check step

Tools that need the compiler API, such as typescript-eslint, use the 6.0 API via @typescript/typescript6. Vue, MDX, Astro, Svelte and Angular template tooling still depend on TypeScript 6 because TypeScript 7 has no stable plugin API, according to the announcement.

Practical example: a staged adoption

Run both compilers side by side, check output parity, and measure on your hardware. The following is an untested sketch; it assumes TypeScript 7.0 installed as typescript and the 6.0 package @typescript/typescript6 providing tsc6, and that hyperfine is installed:

npm install -D typescript @typescript/typescript6

# Same project, both compilers, no emit
hyperfine --warmup 1 'npx tsc6 --noEmit -p .' 'npx tsc --noEmit -p .'

# Try more checker threads on your own core count
npx tsc --noEmit -p . --checkers 8

Then pin the types you rely on explicitly:

{
  "compilerOptions": {
    "types": ["node", "vitest/globals"]
  }
}

Compare error lists from both compilers on one commit. The README states type-checking errors should match TypeScript 6.0, but declaration emit differs significantly by design, and type printing in messages may display differently, so diff error codes and locations rather than raw text.

A caution on reading the table: build time on a continuous-integration runner is often dominated by cold caches, disk and a handful of vCPUs, not the checker alone. A fair test therefore runs both compilers on the same runner type, with incremental build info cleared for the full-build case and kept for the incremental case, and reports the median of several runs together with the core count.

Limitations and failure modes

No programmatic API in 7.0; a new, different API is expected in 7.1. Custom transformers and ts-patch-style plugins will not work.
Declaration emit differences may change generated .d.ts files, which matters for published libraries.
Not every module resolution mode was supported in the README's description of the staging repo, and some tsconfig errors may be less helpful.
The editor: a dedicated VS Code extension is available and built-in support was expected "in the coming weeks" at announcement time; I did not verify the current state.

Engineering recommendations

Adopt for CI type-checking first; keep TypeScript 6 for editor and lint tooling until the API ships.
Fix tsconfig removals and the new defaults in a separate commit from the compiler upgrade.
For libraries, diff generated declarations before publishing.

Conclusion

The speedup is large and the mechanism is plausible: the same checker logic, run natively and in parallel. The cost is in defaults and the missing API. Next step: install both compilers in a branch, run the hyperfine comparison above on your largest package, and record error-code differences before touching production CI.

Sources

I read the official announcement and README and ran nothing myself; benchmark figures are Microsoft's, with unlisted hardware, and the commands are untested.