TypeScript 7.0: What the Go Rewrite Means for Every Developer

In March 2025, Anders Hejlsberg announced that the TypeScript compiler would be rewritten in Go. One year later, the results are in: TypeScript 7.0 delivers 10x faster type-checking, 8x faster project loads, and a native language server that makes editor lag a thing of the past. This is the most significant change to the TypeScript toolchain since the language was created in 2012.

Why a Rewrite? Why Go?

The TypeScript compiler has been written in TypeScript since day one. This was a deliberate bootstrapping choice — "dogfooding" the language proved its capabilities. But after a decade, the self-hosted compiler hit fundamental performance limits. Large codebases with millions of lines of TypeScript routinely took 30-60 seconds to type-check, and editor IntelliSense lagged behind keystrokes in complex files.

The TypeScript team evaluated several languages for the rewrite. Rust was a candidate but its borrow checker added friction for a codebase that relies heavily on shared mutable state during type resolution. C++ was ruled out for maintenance burden. Go was chosen for three reasons:

• Structural similarity to TypeScript. Go's interfaces and structural typing map naturally to how the TypeScript compiler represents types internally. Porting algorithms was more direct than translating to Rust's ownership model.
• Built-in concurrency. Goroutines and channels allow parallel type-checking across files with minimal synchronization overhead. The JavaScript compiler was single-threaded by design.
• Fast compilation and simple deployment. The Go compiler itself is fast, and the resulting binary is a single native executable with no runtime dependencies. No more node_modules for the compiler.

Performance: The Numbers

The TypeScript team shared benchmarks from the native compiler (codenamed "Corsa") running against real-world open-source projects. The improvements are dramatic:

These improvements come from three sources: native code execution (vs JIT-compiled JavaScript), parallel type-checking across CPU cores, and more efficient memory management without a garbage-collected heap the size of a V8 isolate.

What Stays the Same

TypeScript 7.0 is a compiler rewrite, not a language rewrite. The type system, syntax, and language semantics are identical to TypeScript 6.0. Your existing code does not need changes.

• Same tsconfig.json format. Your existing config works without changes. The same compiler options are supported.
• Same type system. Every type, generic, utility type, conditional type, template literal type, and mapped type works identically. The Go compiler passes the full TypeScript conformance test suite.
• Same CLI interface. The tsc command accepts the same flags. Build scripts, CI pipelines, and Makefiles work unchanged.
• Same .d.ts output. Declaration files generated by the Go compiler are identical to those from the JS compiler. Library authors can upgrade without breaking consumers.
• Same error messages. Error codes, messages, and diagnostic output are preserved. Your // @ts-ignore and // @ts-expect-error comments still work.

What Actually Changes

While the language is the same, the tooling and ecosystem around the compiler changes in meaningful ways.

Native Binary Distribution

TypeScript 7.0 ships as a native binary for each platform (macOS arm64, macOS x64, Linux x64, Linux arm64, Windows x64). When you npm install typescript@7, the package includes a thin JS wrapper that delegates to the platform-specific binary. This is the same approach used by esbuild and Bun.

# Install TypeScript 7.0
npm install typescript@7 --save-dev

# The tsc command works identically
npx tsc --noEmit
npx tsc --build

Native Language Server

The old tsserver (a Node.js process that powered editor IntelliSense) is replaced by a native Go-based language server. This is where the 8x project-load improvement and 10x autocomplete speedup come from. VS Code, Neovim, JetBrains IDEs, and any LSP-compatible editor will use the new server automatically.

For most developers, this is the most noticeable change. Large projects that previously caused VS Code to freeze during IntelliSense will now respond instantly. The "TypeScript is initializing..." delay on project open drops from seconds to milliseconds.

Parallel Type-Checking

The Go compiler leverages goroutines to type-check files across all available CPU cores. The JavaScript compiler was limited to a single thread due to V8's execution model. On a machine with 8 cores, type-checking a project with independent modules can be up to 6-8x faster from parallelism alone (before counting the native code advantage).

This particularly benefits monorepos and large codebases where files have minimal interdependencies. The compiler analyzes the dependency graph and type-checks independent sub-graphs concurrently.

Compiler API Changes

The biggest breaking change is for tools that use the TypeScript Compiler API programmatically. The typescript npm package previously exported a full JavaScript API (ts.createProgram, ts.createSourceFile, etc.). In TypeScript 7.0, the compiler is a Go binary — the old JS API is not available.

Instead, TypeScript 7.0 provides:

• A gRPC-based API for programmatic access to type information, diagnostics, and AST data. This is faster than the old JS API because it avoids serializing the entire AST into JavaScript objects.
• A compatibility layer (typescript-compat) that wraps the gRPC API in the old JS API surface for tools that need time to migrate.

Impact on Your Stack

Next.js, Vite, and Bundlers

Bundlers that only use TypeScript for type-checking (not transpilation) work immediately. Next.js, Vite, and webpack all use SWC or esbuild for actual code transformation and delegate to tsc for type checking. Since the CLI interface is unchanged, your build pipeline works as-is.

CI/CD Pipelines

CI pipelines see the most dramatic improvement. A type-check step that previously took 45 seconds now completes in under 5 seconds. For teams with large monorepos, this means faster PR checks and shorter feedback loops.

# Before: TypeScript 6.0 (JS compiler)
# ✓ Type check: 47s
# ✓ Total CI: 3m 12s

# After: TypeScript 7.0 (Go compiler)
# ✓ Type check: 4.8s
# ✓ Total CI: 2m 30s

Monorepos

Monorepos with project references (tsc --build) benefit from both native speed and parallel sub-project checking. A monorepo with 20 packages that took 2 minutes to type-check can drop to 15-20 seconds. The Go compiler processes the project reference graph and checks independent packages concurrently.

Editor Experience

This is where most developers will feel the difference. The native language server means:

• Instant autocomplete, even in files with complex generics or conditional types
• Go-to-definition and find-all-references respond in milliseconds, not seconds
• Error squiggles appear as you type, not after a 1-2 second delay
• Memory usage drops significantly — VS Code no longer needs 2-4 GB for the TypeScript language service on large projects

Preparing Your Codebase

The best thing you can do right now is migrate to TypeScript 6.0. The 6.0 release was designed as a "cleanup release" that removed legacy options and modernized defaults specifically to ease the transition to the Go compiler. If your project builds clean on TypeScript 6.0, it will work on 7.0 without changes.

1. 1Migrate to TypeScript 6.0 first. Follow our TypeScript 6.0 Migration Guide or use the Migration Checker.
2. 2Audit Compiler API usage. Search your codebase for import * as ts from "typescript" or ts.createProgram. If you have custom transformers or codemods, plan to migrate them to the new gRPC API or use the compatibility layer.
3. 3Check your toolchain versions. Ensure typescript-eslint, ts-jest, ts-node, and any TypeScript plugins are updated to versions that support TypeScript 7.0. Most have shipped compatible releases already.
4. 4Generate a clean tsconfig.json. Use the tsconfig.json Visual Builder to create a config from scratch with modern defaults rather than carrying forward years of accumulated options.
5. 5Test with the beta. Install typescript@next and run your full build + test suite. File issues early for any behavioral differences.

A Recommended tsconfig.json for TypeScript 7.0

Here is a minimal, modern config that works with both TypeScript 6.0 and 7.0. Since 6.0 already defaults to most of these values, many lines are optional — included here for explicitness.

{
  "compilerOptions": {
    "target": "es2023",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "noEmit": true,
    "isolatedModules": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "jsx": "preserve",
    "lib": ["dom", "dom.iterable", "es2023"],
    "types": ["node", "react", "react-dom"],
    "incremental": true
  },
  "include": ["src/**/*.ts", "src/**/*.tsx"],
  "exclude": ["node_modules", "dist"]
}

The Broader Trend: Native Rewrites

TypeScript's Go rewrite fits into a larger pattern of JavaScript tooling being rewritten in faster languages. This is not a fad — it reflects the maturing of the ecosystem:

The common thread: JavaScript tooling that was "fast enough" for small projects becomes a bottleneck at scale. Native rewrites fix the bottleneck without changing the user-facing API. For developers, the tools work the same way — they just respond instantly.

FAQ

Do I need to rewrite my code for TypeScript 7.0?

No. TypeScript 7.0 is a compiler rewrite, not a language change. If your code compiles on TypeScript 6.0, it compiles on 7.0 without modification.

Will the old JavaScript compiler still be maintained?

TypeScript 6.x will continue receiving critical bug fixes for a transition period, but all new feature development happens on the Go compiler. The JavaScript compiler is effectively in maintenance mode.

Does this affect my bundler (Vite, webpack, Next.js)?

No. Bundlers that use SWC or esbuild for transpilation and only delegate to tsc for type-checking will work identically. The CLI interface is unchanged.

Can I still use ts-node or tsx?

Yes. tsx (which uses esbuild under the hood) works immediately. ts-node depends on the TypeScript Compiler API and needs a version that supports the compatibility layer or the new gRPC API.

When should I upgrade?

If you are already on TypeScript 6.0 and your toolchain is compatible, upgrade immediately — the performance improvements are free. If you are on TypeScript 5.x, migrate to 6.0 first (the harder step), then upgrade to 7.0.

Bottom Line

TypeScript 7.0 is the rare major version that requires no code changes but dramatically improves the developer experience. Faster type-checking, instant IntelliSense, lower memory usage, and shorter CI times — all for free. The Go rewrite validates a decade-long bet: TypeScript's value was always in the type system, not the implementation language.

Get your codebase ready today. Use the TypeScript 6.0 Migration Checker to ensure you are on a clean 6.0 config, then build a fresh config with the tsconfig.json Visual Builder. And if you are generating TypeScript from other formats, tools like the JSON to TypeScript Generator and GraphQL to TypeScript Converter produce clean output that works with both compilers.