TypeScript 7.0 RC: the compiler is now Go, and it's 10x faster

TypeScript 7.0 RC is out, and the headline is architectural: the compiler has been rewritten from TypeScript (self-hosted) to Go. The practical result is builds that run approximately 10x faster than TypeScript 6.0, with parallelism across parsing, type-checking, and emitting that wasn't possible in the previous implementation.

For large codebases — the kind that Solana ecosystem projects tend to grow into — this is the most meaningful TypeScript release in years. Web3.js, Anchor clients, and Solana dApps that take 30+ seconds to type-check will shrink that to single digits. The flip side: the release ships new defaults and removes several legacy targets that will require config updates.

The RC is installable today. Stable is expected within a month.

Installing the RC

npm install -D typescript@rc

# Verify
npx tsc --version
# Version 7.0.1-rc

To run TypeScript 6 and 7 side-by-side during migration:

npm install -D typescript@npm:@typescript/typescript6
npm install -D typescript-7@npm:typescript@rc

# Then reference explicitly in scripts:
npx typescript-7 --version

The Go compiler: what changed

The TypeScript team ported the entire compiler from self-hosted TypeScript to Go. This was not a rewrite from scratch — it's a port that preserves the existing type system semantics. The goal was performance, not behavioural change.

What Go enables that the TypeScript self-host couldn't:

• True parallelism — Go goroutines mean parsing, type-checking, and emit can overlap across files simultaneously. JavaScript's single-threaded model made this impossible before (worker threads exist but add overhead and complexity).
• Lower memory pressure — Go's garbage collector is tuned for throughput; V8's is tuned for latency. The compiler processes more AST nodes per MB of RAM.
• Native binary — no Node.js startup cost, no JIT warmup. The first file checked is as fast as the last.

Bloomberg, Figma, Google, Notion, Slack, and Vercel all tested the RC against multi-million line codebases. The 10x claim holds across that spread.

Parallel type-checking with --checkers

The new --checkers flag controls how many parallel type-checking workers the compiler spawns. The default is 4.

# Use 8 checkers on a machine with 8+ cores
npx tsc --checkers 8

# Single-threaded mode — useful for debugging or CI with limited resources
npx tsc --singleThreaded

For monorepos with TypeScript project references, the new --builders flag compiles multiple projects in parallel:

# Build all project references in parallel
npx tsc --build --builders 4

Rebuilt watch mode

The --watch implementation was replaced with a port of Parcel's file watcher (originally C++, now Go). The old implementation fell back to polling on large projects; the new one uses native OS file system events across macOS, Linux, and Windows. On a 500k-line project, watch mode CPU usage drops from ~15% idle to effectively zero.

New default compiler options

This is where most migrations will require attention. TypeScript 7.0 changes several defaults that were previously conservative for backwards compatibility:

// What TypeScript 7.0 now assumes if you don't set these:
{
  "compilerOptions": {
    "strict": true,                         // was false
    "module": "esnext",                     // was commonjs
    "target": "es2024",                     // was es3 (!)
    "noUncheckedSideEffectImports": true,   // was false
    "stableTypeOrdering": true,             // new, cannot be disabled
    "types": [],                            // was auto-discovered from node_modules/@types
    "rootDir": "./"                         // was inferred
  }
}

The most impactful change for existing projects is types: []. Previously TypeScript automatically picked up every @types/* package in node_modules. Now you must declare them explicitly if your code relies on global types from @types/node, @types/jest, etc:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Removed targets and module modes

TypeScript 7.0 drops support for output targets and module formats that are no longer in active use:

Removed targets:
  ES5 — use a bundler (esbuild, Rollup, SWC) for ES5 output

Removed module modes:
  amd, umd, systemjs, none

Removed moduleResolution modes:
  classic, node, node10

Removed options:
  baseUrl                       — use paths with explicit root instead
  esModuleInterop: false        — esModuleInterop is now always true
  allowSyntheticDefaultImports: false — always true

If your tsconfig.json sets any of these, TypeScript 7.0 will error. The migration is usually straightforward: swap moduleResolution: node for moduleResolution: bundler or moduleResolution: nodenext.

Unicode template literal inference fix

A long-standing bug with emoji and multi-byte Unicode in template literal types is fixed in 7.0. Previously, TypeScript split on UTF-16 code units, mangling characters outside the BMP:

type HeadTail<S extends string> =
  S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// TypeScript 6:  ["�", "�abc"]  ← broken: split UTF-16 surrogate pair
// TypeScript 7:  ["😀", "abc"]            ← correct: treats emoji as one character

JavaScript / JSDoc changes

The JSDoc-based type analysis that powers JavaScript projects (without .d.ts files) has several breaking changes:

• @enum annotations are no longer recognised — use a TypeScript .ts file with an enum declaration or as const object
• Values can no longer substitute for types in JSDoc — you must use typeof MyValue explicitly
• Standalone ? as a type annotation is removed
• Closure-style function type syntax (function(string): void) is no longer accepted
• @class no longer makes plain functions constructible

Editor integration

The TypeScript Native Preview extension for VS Code is available now. It runs the Go compiler as the language server, replacing the previous TypeScript-based tsserver. The team reports a 20x reduction in failing LSP commands during testing. Semantic highlighting, import sorting, and unused import removal — which were missing in earlier previews — are restored in the RC.

Visual Studio (Windows) automatically enables TypeScript 7 without an extension. JetBrains IDEs and other LSP-compatible editors will follow — the new language server exposes a standard LSP interface rather than a TypeScript-specific protocol.

Programmatic API note

If you use TypeScript's compiler API programmatically (custom transformers, type-checking pipelines, linting tools), TypeScript 7.0 ships without a stable programmatic API. The team is designing it for TypeScript 7.1. For now, tools that depend on ts.createProgram or the compiler internals should stay on TypeScript 6 until 7.1 lands.

Migration checklist

# 1. Install the RC
npm install -D typescript@rc

# 2. Run tsc to surface config errors
npx tsc --noEmit

# Common fixes:

# moduleResolution: node → bundler or nodenext
# Remove: baseUrl
# Remove: target: es5  (use your bundler for downlevel output)
# Remove: module: amd / umd / systemjs
# Add:    types: ["node"]  if you use Node.js globals
# Add:    rootDir: "./src"  if tsc complains about rootDir

# 3. Check strict: true fallout
#    - Implicit any on function parameters
#    - Possibly-null dereferences
#    - Missing return types on exported functions

# 4. Enable parallel checking
npx tsc --checkers 4 --noEmit

What it means for Solana TypeScript

The Solana TypeScript ecosystem — web3.js v2, Anchor TS clients, codama-generated bindings — generates significant amounts of typed code. A mid-sized dApp with generated account types and instruction builders can easily hit 200k+ type-checked lines. TypeScript 6 often makes that a 20–40 second tsc invocation. TypeScript 7 cuts it to 2–4 seconds.

The noUncheckedSideEffectImports default will surface bare imports that were previously silently ignored — common in Solana projects that import buffer polyfills or @solana/webcrypto-ed25519-polyfill as side effects. These are fixable: either add explicit types or suppress the warning per-import.

The module: esnext default aligns with how Vite, Next.js, and most modern Solana frontend toolchains already configure their TypeScript. For most projects that already use a bundler, this is a no-op.

Timeline

• RC available now — npm install -D typescript@rc
• Stable release — expected within one month of the RC
• TypeScript 7.1 — stable programmatic API for tooling authors

The full announcement and migration guide is at devblogs.microsoft.com/typescript.