Microsoft released TypeScript 7.0 on July 8, 2026, with a compiler rewritten entirely in Go. In Microsoft’s published benchmarks, the VS Code codebase took 10.6 seconds to build instead of 125.7 seconds. The release also changes compiler options and leaves an important gap: tools that embed TypeScript through its programmatic API cannot yet use a stable equivalent in the new compiler.
As of July 15, the practical recommendation is to start migrating projects that use tsc directly, including supported React, Next.js, and Node.js setups. Projects that depend on Vue, Svelte, Astro, MDX, or Angular template tooling have a reason to wait for TypeScript 7.1, expected around October 2026.
What the Go rewrite changes
For fourteen years, the TypeScript compiler ran as JavaScript in a Node.js process on V8. That architecture placed limits on how the existing compiler could divide work across CPU cores. It also involved just-in-time compilation, or JIT, which compiles JavaScript into machine code while a process runs and can add warmup time.
Microsoft developed the Go rewrite, internally called Project Corsa, over fifteen months in the public typescript-go repository. Go produces native machine code ahead of time, so the compiler does not need JIT warmup. Its goroutines also provide a way to run compiler work concurrently.
The new compiler exposes three controls for that work:
--checkerscontrols parallel type-checking workers and defaults to four.--buildersenables parallel builds across project references, which connect packages in a TypeScript monorepo.--singleThreadedprovides a single-threaded mode for debugging resource use or running in constrained CI environments.
These changes give the compiler more room to use available CPU resources. Microsoft’s official announcement describes full builds as typically 8x to 12x faster. That is a claim about compiler performance, not a guarantee that an entire application build or CI pipeline will finish that much sooner.
The published results
Microsoft published measurements for five existing projects. They provide more useful context than a single headline multiplier, though they remain vendor-published benchmarks.
| Project | Previous build time | Go compiler build time | Reported speedup |
|---|---|---|---|
| VS Code, 2.3 million lines | 125.7 seconds | 10.6 seconds | 11.9x |
| Sentry | 139.8 seconds | 15.7 seconds | 8.9x |
| Bluesky | 24.3 seconds | 2.8 seconds | 8.7x |
| Playwright | 12.8 seconds | 1.47 seconds | 8.7x |
| TLDraw | 11.2 seconds | 1.46 seconds | 7.7x |
Memory use reportedly fell by 6 to 26 percent across the tested codebases. A separate editor measurement, covering how quickly VS Code displayed a type error after a file changed, fell from 17.5 seconds to 1.3 seconds. That shorter wait could make a noticeable difference during editing, even when a full build is not running.
Reports from teams that have migrated describe similar operational gains. Slack says it reduced merge queue time by 40 percent and cut CI type-checking from 7.5 minutes to 1.25 minutes. Microsoft’s News Services team reports saving 400 hours per month in CI wait time. Canva reports reducing editor error feedback from 58 seconds to 4.8 seconds.
Those measurements describe different parts of development. A faster compiler can shorten a merge queue when type-checking is holding it up, but other jobs may still determine when a change can merge. Editor feedback has a more immediate effect: a developer can see a type error while the relevant change is still fresh.
A full check that takes fifteen seconds rather than two minutes may also encourage more frequent checks instead of larger batches of changes. That is a reasonable workflow expectation, rather than a result established by the timing measurements alone.
Configuration changes to handle before upgrading
TypeScript 7.0 combines completed deprecations with constraints introduced by the new compiler architecture. The configuration changes are likely to be easier for modern projects than the tooling changes, but they still need attention.
- The ES5 target is removed. Projects that still need ES5 output must move that transformation to another tool, such as Babel or esbuild, with suitable support for the required output.
downlevelIterationis removed. Modern JavaScript engines support iterators natively, but projects supporting older environments need to review their transformation requirements.- AMD, UMD, and SystemJS module output formats are removed. Existing projects that rely on these formats need another output path.
baseUrlwithoutpathsis no longer supported. This is a reason to inspecttsconfig.jsonbefore changing the compiler version.strictis enabled by default. Projects that previously relied on the default being off need to review their settings and any newly reported errors.
For a project with a current JavaScript target and a straightforward tsc command, these changes may account for most of the migration work. A project with custom compiler integrations needs a separate compatibility review.
The programmatic API is the main compatibility limit
As Linuxiac reports, TypeScript 7.0 does not yet expose a stable programmatic API. This API is how other tools call into the compiler directly, rather than invoking its command-line interface.
Volar, which powers Vue’s TypeScript integration, depends on that kind of access. So do SvelteKit’s template type-checker, Astro’s IDE support, MDX tooling, and Angular’s template compiler. These integrations need to analyze content that TypeScript does not parse directly, including .vue and .svelte files, framework templates, and JSX embedded in Markdown.
That dependency prevents these tools from simply swapping in the new compiler. Their move depends on a stable Go-based API and corresponding integration work. TypeScript 7.1 is expected to address the API gap around October 2026, with development already taking place publicly.
Microsoft’s proposed bridge is to run TypeScript 7.0 for command-line builds while keeping TypeScript 6 for the editor’s language service. That can provide some of the performance benefit, but it also means maintaining two versions with different roles. For most teams relying on these framework integrations, waiting is the simpler choice.
Which projects should start migrating
The useful dividing line is whether type-checking runs through the CLI or depends on the compiler’s programmatic API. Framework names help identify likely cases, but the tools in the project determine compatibility.
Start the migration for CLI-first projects. The supported group includes React with Vite or webpack, Next.js with TypeScript 7.0 support as of version 16.3, Node.js services, Deno, Bun, and Express or Fastify APIs. Projects where tsc is the primary type-checking tool have the clearest path: install the new version, resolve configuration changes, and compare both diagnostics and timings.
Wait for compatible integrations when template tooling is essential. That includes Vue 3 with Volar, Svelte, Astro, MDX, and Angular projects with template type-checking. The expected TypeScript 7.1 release is the next milestone to watch, though the compiler release alone does not remove the need for support in each integration.
Teams in either group can audit deprecated options now. Removing configuration obstacles early leaves less work for the eventual compiler upgrade.
How faster checks affect CI
A separate type-checking job can consume a substantial share of a CI pipeline’s time. If the reported gains carry over to a project, that job may stop being its main bottleneck.
Teams using 8-core or 16-core runners to divide checks across projects should revisit that arrangement. The Go compiler can parallelize work internally through --checkers, so the old job layout may no longer be the best use of runner capacity. Measurements are still needed before reducing resources, since a smaller runner can also limit that parallelism.
The available time creates several practical options. A team could reduce runner spending, retain the hardware and run more checks, or shorten its target time for changes to pass merge gates. Additional lint checks, coverage requirements, or integration tests may become affordable within an existing time budget. Slack’s reported reduction in merge queue time illustrates the last option.
For monorepos, --builders deserves a separate test. Project references form a dependency graph: package B may need package A to finish, while package C may depend on both B and D. Parallel building can run independent branches at the same time, but it cannot remove those dependencies.
A shared utilities package beneath five separate service packages offers opportunities to build services concurrently once the shared dependency is ready. A long chain in which each package depends on the previous one offers less parallel work. The shape of the graph matters as much as the number of packages.
The open development process, published project benchmarks, and explicit account of the API limitation give teams reasons to evaluate the release. CLI-first projects can measure a migration by recording current timings, updating the compiler and configuration, then comparing results on the same codebase and CI resources. Projects waiting on framework support can prepare their configuration now and track the API and integration work ahead of the expected October release.
