---
title: 'TypeScript 7 (tsgo): 10x Faster Compiler in 2026'
description: TypeScript 7 ports the compiler to Go for roughly 10x faster builds. Install tsgo, the new --checkers flag, the breaking changes, and the 2026 release timeline.
url: https://nerdleveltech.com/typescript-7-native-compiler-tsgo
language: en
date: '2026-06-16'
category: tooling
tags:
  - TypeScript 7
  - tsgo
  - TypeScript Go rewrite
  - native compiler
  - TypeScript performance
  - TypeScript 6
  - JavaScript tooling
  - tsc
markdown_url: https://nerdleveltech.com/typescript-7-native-compiler-tsgo.md
attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/typescript-7-native-compiler-tsgo'
terms: https://nerdleveltech.com/llms.txt
---

# TypeScript 7 (tsgo): 10x Faster Compiler in 2026

**TypeScript 7 is a native port of the compiler and tooling from JavaScript to Go. Microsoft says it runs about 10x faster than TypeScript 6, and the release candidate landed on June 18, 2026 — one npm command away from trying it yourself. Here's exactly what shipped, what breaks, and when the stable release is expected — sourced from Microsoft's own announcements.**

## TL;DR

- **TypeScript 7 (codename "Corsa")** is a native port of the `tsc` compiler, language service, and tooling from the bootstrapped JavaScript codebase to **Go**.[^1][^2]
- Microsoft says it is **"often about 10 times faster than TypeScript 6.0,"** thanks to native code speed plus shared-memory parallelism.[^2]
- The **public beta landed on April 21, 2026**. Install it with `npm install -D @typescript/native-preview@beta` and run **`tsgo`** in place of `tsc`.[^2]
- On Microsoft's published `tsc` benchmarks, the native port checked the **1.5M-line VS Code codebase in 7.5s vs 77.8s (10.4x)** and cut **editor project-load time from ~9.6s to ~1.2s (8x)**, with roughly **half the memory**.[^1]
- It introduces **real breaking changes**: `strict` on by default, `module` defaults to `esnext`, and a list of deprecated flags (`target: es5`, `baseUrl`, `moduleResolution: node`, and others) that are now **hard errors**.[^2]
- As of **early July 2026, TypeScript 7 has reached release candidate (RC) status** — the RC shipped **June 18, 2026**. Microsoft's stated plan targets stable **within about a month of the RC**, putting general availability at roughly **mid-to-late July 2026**.[^6]

## What You'll Learn

- What TypeScript 7 actually is, and how it differs from TypeScript 6
- The performance numbers Microsoft published — and what the baseline really is
- How to install `tsgo` and run it side-by-side with your current `tsc`
- The new parallelism controls: `--checkers`, `--builders`, and `--singleThreaded`
- Which config flags and patterns break when you upgrade
- Why Microsoft chose Go over Rust or C#
- Where the stable 7.0 release stands as of July 2026

## What TypeScript 7 Is

TypeScript 7 is the release name for the **native port of the TypeScript compiler**. For its entire life, `tsc` has been written in TypeScript and run as JavaScript on Node.js, which means it inherits V8's garbage collector and single-threaded execution model. Over roughly a year, Microsoft rebuilt that codebase in Go.[^1][^2]

A key detail that gets lost in the "rewrite" headlines: this is a **port, not a redesign**. As the TypeScript team put it, the Go codebase "was methodically ported from our existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0."[^2] In other words, the type system you already know is unchanged — the same `.ts` files that compile under TS 6 are meant to compile identically under TS 7, just much faster.

Microsoft uses two internal codenames you'll see in commits and discussions: **"Strada"** for the original TypeScript codebase, and **"Corsa"** for the native port.[^1] For naming going forward, the team refers to them simply as **TypeScript 6 (JS)** and **TypeScript 7 (native)**.[^1]

## How Much Faster Is It, Really?

The headline is "10x," and Microsoft's framing in the beta announcement is specific: TypeScript 7.0 is **"often about 10 times faster than TypeScript 6.0."**[^2] That speedup comes from two things working together — compiled native code instead of interpreted JavaScript, and **shared-memory parallelism** that the old single-threaded runtime couldn't exploit.[^2]

When Microsoft first announced the native port in March 2025, it published `tsc` command-line timings across well-known open-source codebases. These compare the native port against the existing JavaScript-based compiler:[^1]

| Codebase | Size (LOC) | JS-based `tsc` | Native | Speedup |
|---|---|---|---|---|
| VS Code | 1,505,000 | 77.8s | 7.5s | 10.4x |
| Playwright | 356,000 | 11.1s | 1.1s | 10.1x |
| TypeORM | 270,000 | 17.5s | 1.3s | 13.5x |
| date-fns | 104,000 | 6.5s | 0.7s | 9.5x |
| tRPC (server + client) | 18,000 | 5.5s | 0.6s | 9.1x |
| rxjs (observable) | 2,100 | 1.1s | 0.1s | 11.0x |

The speedups cluster around an order of magnitude regardless of project size, which is why the "10x" shorthand stuck.[^1]

The number most developers will actually feel, though, is **editor startup**. Using the VS Code codebase as a benchmark, Microsoft measured the time to load the entire project in the editor dropping from **about 9.6 seconds to about 1.2 seconds — an 8x improvement** in project-load time.[^1] Overall memory usage came in at **roughly half** the JavaScript implementation, with the team noting they hadn't even optimized for memory yet.[^1]

One honest caveat for anyone repeating these figures: the benchmark table above is from the original 2025 announcement and measures the native port against the then-current JS compiler. The "10x vs. TypeScript 6.0" claim is the one Microsoft attached to the actual 7.0 beta.[^1][^2] Both are Microsoft's own numbers on Microsoft's own hardware — representative, but not an independent benchmark.

## Installing and Running tsgo

You don't have to wait for the stable release to try it, and how you install it depends on which milestone you're targeting. The **April 2026 beta** shipped under a preview package name with a separate binary so it couldn't collide with your existing toolchain:[^2]

```sh
npm install -D @typescript/native-preview@beta
```

```sh
npx tsgo --version
# Version 7.0.0-beta

npx tsgo --project tsconfig.json
```

That `tsgo` binary "has the same behavior on all TypeScript code as `tsc` from TypeScript 6.0 — just much faster."[^2] The nightly builds under `@typescript/native-preview` still publish this way today.[^6]

With the **June 18, 2026 release candidate**, the native compiler moved onto its final path: it now installs as the regular **`typescript`** package, and the Go-native binary answers to the familiar **`tsc`** entry point directly — no separate `tsgo` command needed:[^6]

```sh
npm install -D typescript@rc
```

```sh
npx tsc --version
# reports a 7.0 RC build
```

That's the version worth testing against your CI now that it's RC-stage — it's the closest preview to what stable 7.0 will actually ship.[^6]

For the editor, install the **TypeScript Native Preview** extension for VS Code. It's built on the **Language Server Protocol (LSP)** — a long-planned infrastructure change that aligns TypeScript with how other languages integrate into editors — so it can run in most modern editors, not just VS Code.[^1][^2]

### Running side-by-side with TypeScript 6

Because the stable 7.0 will eventually claim the `tsc` name, Microsoft published a compatibility package, **`@typescript/typescript6`**, which exposes a **`tsc6`** entry point and re-exports the TypeScript 6.0 API.[^2] That lets tooling which imports from `typescript` directly (typescript-eslint, for example) keep working. The recommended approach is an npm alias:[^2]

```sh
npm install -D typescript@npm:@typescript/typescript6
```

## The New Parallelism Controls

The biggest architectural change Go unlocks is **doing work in parallel**. TypeScript 7 parallelizes parsing, type-checking, and emitting — steps that the single-threaded JavaScript runtime had to do one at a time.[^2] Three new flags give you control over that:

- **`--checkers`** sets the number of type-checking workers. The **default is 4**. Each worker gets its own view of the program; given the same inputs they divide work identically and produce the same results. More checkers can speed up large codebases on many-core machines, at the cost of memory. CI runners with few cores may want fewer.[^2]
- **`--builders`** controls how many project-reference builders run at once — useful for **monorepos** with many composite projects. It multiplies with `--checkers`, so `--checkers 4 --builders 4` can spawn up to 16 type-checkers simultaneously, which Microsoft notes "may be excessive."[^2]
- **`--singleThreaded`** forces everything onto one thread. It's meant for debugging, apples-to-apples comparisons with TypeScript 6, or resource-constrained environments.[^2]

One subtlety worth flagging for teams: in rare cases, varying `--checkers` can surface **order-dependent results**, so Microsoft suggests fixing a checker count across your team for consistency.[^2]

## Breaking Changes You Need to Plan For

"Structurally identical type-checking" does **not** mean "drop-in upgrade." TypeScript 7 adopts TypeScript 6.0's new defaults and turns previously deprecated options into **hard errors**.[^2] This is exactly why Microsoft shipped TypeScript 6 first as a JavaScript-based **bridge release** — it introduced the deprecations so the jump to 7 would be smaller.[^2][^4]

The notable default changes:[^2]

- `strict` is now **`true`** by default.
- `module` defaults to **`esnext`**.
- `target` defaults to the current stable ECMAScript version immediately preceding `esnext`.
- `noUncheckedSideEffectImports` is **`true`** by default.
- `stableTypeOrdering` is **`true`** and **cannot be turned off**.
- `rootDir` now defaults to `./` (projects whose `tsconfig.json` sits outside `src` should set it explicitly).
- `types` now defaults to **`[]`** — list the `@types` packages you need (e.g. `["node", "jest"]`) explicitly.

And the deprecated options that are now hard errors with no-op behavior:[^2]

- `target: es5` and `downlevelIteration` are **no longer supported**.
- `moduleResolution: node`/`node10` and `moduleResolution: classic` are gone — use `nodenext` or `bundler`.
- `module: amd`, `umd`, `system`, and `none` are gone — use `esnext` or `preserve` with a bundler.
- **`baseUrl` is no longer supported** — make `paths` relative to the project root instead.
- `esModuleInterop` and `allowSyntheticDefaultImports` can no longer be set to `false`.

There's also a quieter set of **JavaScript/JSDoc changes**: TypeScript 7 reworked its JS support to behave more like its `.ts` analysis, so some Closure-style JSDoc patterns (`@enum`, `@class` on a function, standalone `?` as a type, Closure function syntax) are no longer specially recognized.[^2] If you have a large JS-with-JSDoc codebase, budget time to test it.

If you maintain tooling, note one more thing: a **stable programmatic API won't arrive until TypeScript 7.1 or later** — "at least several months" after the 7.0 beta.[^2] If your build depends on importing the compiler API, that's a reason to stay on TypeScript 6 for now.

## Why Go, and Not Rust or C#?

This was the internet's favorite argument when the port was announced, so it's worth getting right. Lead architect **Anders Hejlsberg** said the team prototyped the port in several languages and found Go the best fit. The core reason is pragmatic: the existing compiler leans heavily on **shared mutable data structures, reference graphs, and pointer-heavy traversals**, and translating that to Go was far more straightforward than to Rust — whose borrow checker would have forced a fundamental redesign of those data structures.[^5]

Hejlsberg described Go as roughly the lowest-level language that still offered optimized native code on every platform, good control over data layout, support for cyclic data structures, **automatic memory management** via a garbage collector, and strong concurrency through goroutines.[^5] TypeScript dev lead **Ryan Cavanaugh** put the Rust question succinctly: Rust "succeeds wildly at its design goals, but 'is straightforward to port to Rust from this particular JavaScript codebase' is very rationally not one of its design goals."[^5]

So this wasn't a referendum on which language is "better" — it was about which language let Microsoft port a decade-old, pointer-graph-heavy codebase with the highest fidelity and lowest risk.

## Where the Stable Release Stands (July 2026)

At the April 21, 2026 beta, Microsoft said its plan was to **release TypeScript 7.0 within the next two months, with a release candidate a few weeks prior**.[^2] That plan held: the **release candidate shipped June 18, 2026**, moving the Go-based compiler into what Microsoft calls the mainline path toward 7.0.[^6] With the RC out, Microsoft's stated target for general availability is **within about a month of the RC** — roughly **mid-to-late July 2026** — though, as with the earlier beta timeline, this is the team's own estimate rather than a fixed, committed date.[^6]

It is not vaporware, though. Microsoft says the beta ran on **multi-million-line codebases inside and outside the company**, and that teams at **Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel, and VoidZero** tested pre-release builds, reporting similar speedups.[^2] The "beta" label was already more conservative than it sounded — Microsoft explicitly said you could "probably start using this in your day-to-day work immediately."[^2] With the RC now out, that guidance applies even more directly: this is the version teams should be validating in CI ahead of the stable cutover.[^6]

If you want to go deeper on the language-design tradeoffs behind all this, our [deep dive into Python, JavaScript, TypeScript, Go, and Rust](python-javascript-typescript-go-and-rust-a-deep-dive-into-modern-programming-too) covers why these ecosystems keep converging on native tooling. And if you're upgrading a TypeScript service, our [gRPC in Node.js and TypeScript production guide](grpc-nodejs-typescript-production-guide) and [MCP server in TypeScript tutorial](mcp-server-typescript-oauth-streamable-http-production-tutorial) are both built on configs that benefit directly from `tsgo`'s faster checks.

## FAQ

**Is TypeScript 7 available now?**
Yes. It's been available as a **beta** since April 21, 2026 (via `@typescript/native-preview`), and reached **release candidate (RC)** status on June 18, 2026, via `typescript@rc`.[^2][^6] The **stable** release is still pending as of early July 2026; Microsoft's plan targets roughly mid-to-late July 2026, about a month after the RC.[^6]

**Will my existing code break?**
Type-checking is structurally identical to TypeScript 6, so clean TS 6 code should compile the same. But TypeScript 7 turns several deprecated config flags (`target: es5`, `baseUrl`, `moduleResolution: node`, `module: amd/umd/system`) into **hard errors**, and flips defaults like `strict` to `true`. Most breakage is in `tsconfig.json`, not your source.[^2]

**Is it really 10x faster?**
Microsoft says TypeScript 7 is "often about 10 times faster than TypeScript 6.0," and its published `tsc` benchmarks (e.g., VS Code: 77.8s → 7.5s) back the order-of-magnitude claim. These are first-party numbers, not independent benchmarks.[^1][^2]

**How do I run it without breaking my current setup?**
For the current release candidate, install `typescript@rc` — it uses semver-style tagging so it won't silently replace a pinned TypeScript 6 install. Nightly builds are still available separately via `@typescript/native-preview`, with its own `tsgo` binary that runs side-by-side with your existing `tsc`. For tools that import `typescript` directly, alias the compatibility package `@typescript/typescript6`.[^2][^6]

**Why did Microsoft pick Go?**
The existing compiler relies on shared mutable, pointer-heavy data structures that port cleanly to Go's model (with garbage collection and goroutine concurrency), whereas Rust's borrow checker would have demanded a redesign. It was about port fidelity, not raw language ranking.[^5]

**Does it work in editors other than VS Code?**
Yes. The native language service is built on **LSP**, so it works in any LSP-capable editor. The TypeScript Native Preview VS Code extension is the easiest on-ramp.[^1][^2]

## The Bottom Line

TypeScript 7 is the most consequential change to the TypeScript toolchain in a decade — not because the language changed, but because the **compiler got an order of magnitude faster** without changing the semantics you depend on. The practical playbook today: install `typescript@rc` (or `@typescript/native-preview` for nightlies), run it against your CI and local builds to confirm the speedup, and use this pre-GA window to clean up the `tsconfig.json` flags that will become hard errors. Adopting **TypeScript 6 first** makes the eventual jump to 7 almost boring — which, for a port this ambitious, is exactly what you want.

---

## Related reads

- [Migrate from ESLint + Prettier to Biome (2026 Guide)](https://nerdleveltech.com/migrate-eslint-prettier-to-biome)

[^1]: Anders Hejlsberg, "A 10x Faster TypeScript," TypeScript DevBlog (Microsoft), March 11, 2025. https://devblogs.microsoft.com/typescript/typescript-native-port/
[^2]: Daniel Rosenwasser, "Announcing TypeScript 7.0 Beta," TypeScript DevBlog (Microsoft), April 21, 2026. https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/
[^3]: microsoft/typescript-go, "Staging repo for development of native port of TypeScript," GitHub. https://github.com/microsoft/typescript-go
[^4]: Daniel Rosenwasser, "Announcing TypeScript 6.0," TypeScript DevBlog (Microsoft), March 23, 2026. https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/
[^5]: David Cassel, "Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#," The New Stack, 2025. https://thenewstack.io/microsoft-typescript-devs-explain-why-they-chose-go-over-rust-c/
[^6]: TypeScript Team, "Announcing TypeScript 7.0 RC," TypeScript DevBlog (Microsoft), June 18, 2026. https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/