# TypeScript 7 Is Here — The 10x Native Compiler, and Whether You Should Switch Now

> TypeScript 7 has shipped, reborn in Go. Real benchmarks (VSCode: 125s to 10s), the new strict-by-default config, side-by-side installs with 6.x — everything you need to decide whether to switch today.

**Published:** 2026-07-09 | **Updated:** 2026-07-09

---


"Kicking off tsc and going for coffee" — every frontend developer has made that joke at least once. That joke may have just lost its punchline. **On July 8th, 2026, Microsoft shipped TypeScript 7.0**: the compiler and language service, ported whole to Go and running as a native binary. If you tried the preview under the name `tsgo` (`@typescript/native-preview`), this is its stable form — a preview that was already pulling 8.5M+ weekly downloads. Official numbers put full type checks on large projects at **8–12x faster**.

This article packs three things: **why it got this fast**, **what breaks in your tsconfig** when you upgrade, and **whether you should switch now** (spoiler: the answer depends on your project type). There's also a benchmark I ran myself on a small project.

---

## What shipped — in three lines

- The entire compiler and language service were reborn as **native Go** (internal codename Corsa; the legacy JS implementation is Strada). It's a **methodical port**, not a ground-up rewrite — type-checking semantics are structurally identical to 6.0.
- Measured **8–12x**: type-checking the VSCode codebase went from 125.7 seconds to 10.6.
- But a **config spring-cleaning** came along for the ride. `strict` is now the default, and legacy options like `target: es5` are hard errors — which is why the second half of this article exists.

---

## Why is it this fast

The speed comes from three places.

**First, native code.** Until now, tsc was written in TypeScript and ran on Node.js — every run woke up a JS engine, parsed the code, and waited for the JIT to warm up. A Go-compiled binary skips that entire ritual. Asked "why Go?", the team pointed to **structural compatibility with the existing implementation** — any other language would have meant a rewrite instead of a port. That choice is exactly what makes the "identical results to 6.0" guarantee possible. The community verdict was much the same: a pragmatic decision to drop the self-hosting dogma.

**Second, shared-memory multithreading.** The old compiler was effectively single-threaded. TS 7 runs type checkers in parallel — 4 by default (`--checkers 4`), and you can turn it off with `--singleThreaded`. Got cores to spare? Push harder: `--checkers 8` takes VSCode to 16.7x. The era of eight cores sitting idle is over.

As a bonus, `--watch` mode was rebuilt on a new file watcher (Parcel's watcher, ported to Go) — the loop that runs on every save got faster wholesale.

**Third, a generational change in the editor.** The language server was rebuilt on LSP (Language Server Protocol). Opening a large project in VS Code used to take 17.5 seconds before errors appeared; now it's 1.3 — you may feel this more than the compile times. Failed language-server commands are down 80%, crashes down 60%.

{{< img src="images/contents/corsa-vs-strada-en.png" alt="An architecture comparison of TypeScript 6 Strada and 7 Corsa - on the left, Strada runs single-threaded type checking on top of Node.js; on the right, Corsa is a native Go binary running four parallel checker threads, connected to editors via LSP" >}}

---

## Reading the benchmarks as felt time

The official measurements:

| Project | TS 6.0 | TS 7.0 | Speedup |
|---|---|---|---|
| VSCode | 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 |

{{< img src="images/contents/ts7-benchmarks-en.png" alt="A horizontal bar chart comparing type-check times between TypeScript 6 and 7 - VSCode drops from 125.7 seconds to 10.6, Sentry from 139.8 to 15.7, with all five projects showing 8x to 12x reductions" >}}

If the numbers feel abstract, read them like this: a two-minute type check is **time to open a PR and wander off**; ten seconds is **time you wait in your chair**. In CI it converts to money — Slack's type-check CI went from 7.5 minutes to 1.25, and Microsoft's News Services team reports saving 400 hours of CI time per month. Memory is down 6–26% too.

In the time it took you to read this paragraph, all of VSCode finished type-checking. It used to take a chapter, not a paragraph.

Oh no. There goes our coffee-break excuse!!

{{< img src="images/contents/ts7-coffee-break-en.png" alt="A cartoon of a developer holding coffee - the monitor shows a terminal where tsc finished in 10.6 seconds with 0 errors, while the bespectacled developer holds a freshly brewed mug with a deflated expression and a sweat drop, saying 'Wait, it's done ALREADY? I literally just poured the water…' A caption notes we just lost our official excuse to slack off" >}}

### What about small projects? I measured

The launch benchmarks are all giant codebases, so I ran the comparison on this blog's [testing-series demo app](https://github.com/IsaacEryn/frontend-testing-lab) (763 files, a small React+Vitest project). Same machine, three runs each:

```bash
# TS 6.0.3
$ time tsc6 -p tsconfig.test.json --noEmit   # 0.57s / 0.58s / 0.58s

# TS 7.0.2 (default, 4 checkers)
$ time tsc -p tsconfig.test.json --noEmit    # 0.09s / 0.09s / 0.10s

# TS 7.0.2 --singleThreaded
$ time tsc ... --singleThreaded              # 0.17s / 0.16s / 0.17s
```

**About 6x even on a small project.** The decomposition is the interesting part — single-threaded alone gets 3.5x (the native-code and startup-overhead share), and multithreading earns the rest. If you were thinking "our project is small, this won't matter": the difference between 0.6s and 0.1s compounds forever in watch mode and editor responsiveness.

---

## What changed — so your tsconfig isn't surprised

The speed is free; the upgrade isn't. TS 7 spring-cleaned old defaults and options. **Changed defaults** first:

| Option | 6.0 default | 7.0 default |
|---|---|---|
| `strict` | false | **true** |
| `module` | situational | **esnext** |
| `target` | es5-era | latest stable ES before esnext |
| `types` | auto-discovered | **`[]` (explicit)** |
| `rootDir` | computed | **`./`** |
| `noUncheckedSideEffectImports` | false | **true** |

And the things that are now **hard errors** — with prescriptions:

- Error about `target: es5` → raise the target to `es2017`+. If you truly need ES5 output, transpiling belongs to a separate tool (babel/swc) these days.
- Error about `baseUrl` → `paths` is now anchored to the tsconfig location. Delete the `baseUrl` line and adjust `paths` to relative form.
- Error about `moduleResolution: node` (node10) → switch to `bundler` or `nodenext`. Vite-family projects are mostly on `bundler` already — no wind in that zone.
- Error about `downlevelIteration` → an ES5-era iterator-lowering option. If you raised the target, just delete it.
- Errors about `amd`/`umd`/`systemjs` modules → if you genuinely need those formats, staying on 6.x is the right call (see the side-by-side strategy below).
- Global types suddenly missing → that's the `types` default change. List what you use: `"types": ["node", "vitest/globals"]`.
- In JS files, JSDoc `@enum`, postfix `!`, and other Closure-style syntax are no longer supported.

One small but welcome change — in template literal types, emoji and other multi-byte characters are now treated as single units instead of being split into UTF-16 surrogates.

---

## Five accessibility angles

True to this blog, here's the angle the announcement didn't dwell on.

{{< img src="images/contents/ts7-silent-diagnostics-en.png" alt="A two-panel comparison of how language server delays feel to different developers - on the left, a sighted developer waits while at least seeing a spinner; on the right, a developer using a screen reader waits in total silence with no signal at all; a banner below notes TypeScript 7 cut the wait itself from 17.5 seconds to 1.3" >}}

**The biggest winners may be developers who code with assistive technology.** Crashes down 60%, first diagnostics from 17.5s to 1.3s — for a sighted developer that's "nicer"; for a developer working through a screen reader it's a different dimension. A spinner on screen is at least visible. A language server that silently takes its time is, to a screen reader user, **silence without any signal**. Fast, stable tooling is accessibility for the development environment itself.

**`strict` by default catches accessibility code's most common bug.** Think of focus management: the moment `ref.current` is null in `ref.current.focus()`, a keyboard user's focus falls into the void. Strict null checks block that at compile time and push you toward `ref.current?.focus()`. Plenty of projects have been running without that safety net because "enabling strict is a hassle" — now it's the default.

**The surrogate change has a quiet benefit too.** Slice a string through an emoji and the screen shows a broken box while a screen reader reads a meaningless character. Treating multi-byte characters as single units shrinks the surface area for that whole class of accident.

**A fast feedback loop is cognitive accessibility, too.** A two-minute type check isn't just a delay — it's a **break in concentration**: you open another tab while waiting, and coming back means rebuilding the context you had. For developers with a high cost of attention-switching (ADHD, among others), that break is far more expensive than for others. A loop that answers the moment you save removes the cost altogether.

**The CI time you save becomes a budget for accessibility checks.** Plenty of teams say "our pipeline is already too slow to add an axe scan." The day your type checks drop from minutes to seconds is the best possible day to propose [putting automated accessibility checks into the pipeline](/en/series/frontend-testing-done-right/) with the time you just got back.

---

## Should you switch now — the decision

{{< img src="images/contents/ts7-decision-en.png" alt="A decision flowchart for adopting TypeScript 7 - if you depend on Vue, Svelte, Astro or Angular template tooling, wait for 7.1; if you need legacy module formats, stay on 6.x or run both; a typical TS, React or Node project should upgrade now" >}}

**Go now.** A typical TS/React/Node project — especially a team whose CI type checks run in minutes — should switch today. Since it's a port that preserves 6.0 semantics, once you clear the tsconfig items above, code-level surprises are rare. The validation scale is reassuring too: this stable release landed after being hammered on Microsoft's own Office, Teams, and Xbox codebases plus 13+ external organizations including Bloomberg, Canva, Figma, Google, and Slack.

**Wait.** TS 7.0 shipped **without a public API** (the new one is slated for 7.1). Tools that embed TypeScript as a library — template type support for **Vue, Svelte, Astro, MDX, and Angular** (the Volar family), plus **typescript-eslint** — are still tied to 6.x. If those frameworks are your daily driver, watching for 7.1 is the right answer.

typescript-eslint being on the list sounds like "so nobody can go," but no: you can **keep lint running on 6.x while moving `tsc` type checks and your editor to 7**. The side-by-side strategy below exists for exactly that scenario.

**Both — the side-by-side strategy.** 6.x continues as the `@typescript/typescript6` package, so npm aliases let them coexist:

```json
{
  "devDependencies": {
    "typescript": "^7.0.2",
    "@typescript/typescript6": "^6.0.2"
  }
}
```

This gives you two executables side by side — calling `tsc` runs 7, calling `tsc6` runs 6. For example: run CI type checks on the fast 7, and leave the typescript-eslint side untouched on 6. One gotcha I personally stepped on — depending on install order, `node_modules/.bin/tsc` can end up pointing at the 6-side binary. After a side-by-side install, **verify with `npx tsc --version`**. (I re-ran my entire first benchmark because of this.)

Editors are simpler: in VS Code, toggle with the "Enable/Disable TypeScript 7 Language Server" commands; WebStorm and others attach via LSP.

---

## The 10-minute migration walkthrough

The actual sequence:

```bash
# 1. Install (right after launch the latest tag may lag — pinning is safer)
npm i -D typescript@7

# 2. Verify — is it 7.0.x?
npx tsc --version

# 3. Just run it
npx tsc --noEmit
```

If step 3 errors, it's almost certainly one of the prescriptions above. On the demo app, explicit `types` (`vitest/globals`) and an already-`bundler` module resolution meant it passed with zero changes — if your project is based on a recent Vite/Next template, odds are yours will too. If a `src/` layout trips a `rootDir` error, one line — `"rootDir": "./src"` — fixes it.

Finally, measure before and after, and share the numbers with your team. Numbers end adoption debates.

---

## The one-page recap

{{< img src="images/contents/ts7-summary-card-en.png" alt="A one-page TypeScript 7 recap card with five blocks: 1 What (same checks, new engine, native Go port) 2 How much (8-12x on large repos, VSCode 125.7s to 10.6s) 3 Careful (config spring-cleaning with strict on by default) 4 Wait (7.0 has no public API, Vue and typescript-eslint watch for 7.1) 5 Side by side (typescript6 alias gives tsc and tsc6, verify .bin)" >}}

- TypeScript 7 = the compiler and language service **ported to native Go** (stable 2026-07-08) — type-checking semantics match 6.0
- Speed comes from three places: native code + 4 parallel checkers + LSP editor — 8–12x on large repos, ~6x even small (measured)
- **Changed defaults** (`strict: true`, `types: []`…) plus **removed legacy options** (`es5`/`baseUrl`/`node10`) — prescriptions per error above
- The language server's speed and stability are a **bigger win for developers using assistive technology** — tooling accessibility is accessibility
- **7.0 has no public API** — Vue/Svelte/Astro/Angular template tooling and typescript-eslint wait for 7.1 (running lint on 6 meanwhile works)
- Side-by-side installs (`@typescript/typescript6`) work — but check which binary `.bin/tsc` is, with `--version`

---

## Frequently asked questions

**How long will TypeScript 6.x be available?**
It continues as the `@typescript/typescript6` package. With the tooling ecosystem still depending on the 6.x API, maintenance is structurally guaranteed for a while. The center of gravity for new features, though, has moved to 7.

**Do I have to upgrade my existing project?**
No rush — 6.x isn't going to stop working overnight. But if your CI type checks take minutes, the savings dwarf the upgrade cost (mostly a few tsconfig lines). Following the prescriptions here, it's usually under ten minutes.

**Is this relevant if I build with Vite or esbuild?**
Yes — that setup is precisely the winner. When a bundler handles transpiling, tsc's only job is `--noEmit` type checking, and that's exactly the part that just got 8–12x faster. And the editor responsiveness gains apply regardless of build tooling.

---

## The thing to watch is 7.1

To sum up — a typical app project should upgrade now and pocket the speed; if you sit on a framework toolchain, 7.1's new API is the thing to watch. 6.x lives on as `@typescript/typescript6`, so there's no need to trip over yourself rushing.

Incidentally, things like the `typecheck` script from this blog's [testing environment setup article](/en/posts/frontend-testing-setup-vitest/) are exactly this release's beneficiaries — every `tsc --noEmit` in your CI can get several times faster starting today.

For over a decade, tsc was the "slow but precise" friend. Now it's fast too. As for coffee… let's just drink it when we actually want some.

**Sources**
- [Announcing TypeScript 7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) (Microsoft, 2026-07-08)
- [Announcing TypeScript 7.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/)
- [TypeScript 7 native preview in Visual Studio 2026](https://developer.microsoft.com/blog/typescript-7-native-preview-in-visual-studio-2026)
- [GeekNews discussion thread](https://news.hada.io/topic?id=31249) — reactions and adoption stories from the Korean dev community