TypeScript 7.0: Native Go Compiler Reaches Release Candidate

TypeScript 7.0 Release Candidate: A Native Compiler Overhaul

On June 18, 2026, TypeScript 7.0 entered Release Candidate status. Microsoft's estimate points to a General Availability release roughly one month later—a target, not a guarantee. What makes this milestone worth watching is not a new language feature, but a fundamental architectural shift: the compiler itself has been rewritten in Go.

For five major versions, TypeScript compiled with a JavaScript implementation. Version 7.0 marks the debut of a native binary built from Go. The performance gain is dramatic: type-checking operations run approximately 10x faster according to Microsoft's benchmarks. As a concrete example, the VS Code codebase—roughly 1.5 million lines of TypeScript—now type-checks in 7.5 seconds. Before, the same operation took 78 seconds.

This isn't about shaving milliseconds off build times. In a large team, faster type-checking changes the feedback loop, the responsiveness of your editor, and the economics of your CI pipeline.

How the Rewrite Happened: "Strada"

Internally, this effort was codenamed "Strada." Microsoft's compiler team took the existing JavaScript implementation and systematically migrated it to Go, file by file, maintaining the same type-checking logic and output. The goal: identical behavior, not a rewrite from scratch.

The team reached an RC milestone when the Go implementation had covered approximately 85% of the TypeScript compiler. Crucially, every diagnostic—every error, warning, and suggestion—must match the current JavaScript compiler exactly. The new compiler was tested for diagnostic equivalence across Microsoft's own codebases before the RC was cut.

The speed gain stems from two sources: native binary execution (no JavaScript runtime overhead) and the ability to parallelize work across multiple threads with shared memory, something more constrained in the JavaScript ecosystem.

Trying the RC: Installation and Shadow Testing

To test TypeScript 7.0 RC locally, install from npm:

npm install -D typescript@rc

The tsc binary you get is the Go-native compiler. There is no separate command; the binary that lands in node_modules/.bin/tsc is already the new implementation.

For production use, we recommend a shadow CI strategy rather than an immediate cutover. The idea is simple: run the RC in parallel with your stable TypeScript, compare diagnostics, and only switch when you've verified identical output.

Shadow CI Example

Add a script to your package.json that runs both versions:

{
  "scripts": {
    "type-check": "tsc --noEmit",
    "type-check:rc": "npm install -D typescript@rc && tsc --noEmit"
  }
}

In CI, run both in separate jobs and collect the output:

# GitHub Actions example
jobs:
  type-check-stable:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm install
      - run: npm run type-check > stable.txt 2>&1
      - uses: actions/upload-artifact@v4
        with:
          name: stable-diagnostics
          path: stable.txt
 
  type-check-rc:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm install
      - run: npm run type-check:rc > rc.txt 2>&1
      - uses: actions/upload-artifact@v4
        with:
          name: rc-diagnostics
          path: rc.txt
 
  compare-diagnostics:
    needs: [type-check-stable, type-check-rc]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
      - run: diff stable-diagnostics/stable.txt rc-diagnostics/rc.txt || true

Run this alongside your main CI for at least one week. If the diagnostics are identical, you have high confidence for migration.

Nightly Builds: native-preview and tsgo

For teams who want to track the absolute latest development, the nightly @typescript/native-preview package exposes a tsgo command:

npm install -D @typescript/native-preview
npx tsgo --version

This gives you the bleeding-edge implementation. Stability is lower than the RC, so use this only in local development or experimental projects, not in production CI.

Why 10x Performance Matters in Practice

Faster type-checking sounds like a benchmarking win. In reality, it reshapes how large teams work.

Editor responsiveness improves dramatically. Every keystroke triggers type-checking in the background. A 7.5-second type-check for the entire VS Code codebase means autocomplete latency drops from observable delays to near-instant feedback.

CI feedback loops compress. In monorepos, type-checking is often the critical path. Cutting it from 5 minutes to 30 seconds changes how developers think about commit frequency and pre-push checks.

Pre-commit hooks become practical. When tsc --noEmit completes in seconds, teams can enforce stricter type-checking gates at commit time without frustrating developers.

You can run stricter checks more often. With time no longer a constraint, you might enable additional diagnostics, stricter tsconfig settings, or more aggressive type-narrowing checks. The speed makes the rigor affordable.

Platform-Specific Binaries: What You Need to Know

A native binary is inherently platform-specific. The npm package for typescript@rc includes pre-compiled binaries for:

• Windows (x86_64)
• macOS (Intel and Apple Silicon)
• Linux (x86_64 and ARM)

For most CI environments, one of these will match your runner. But if you use a custom or unusual architecture—ARM-based edge runners, or older CI platforms—verify that a binary exists before committing to the RC.

How to Check

Run npm install typescript@rc in your CI environment and attempt tsc --version. If the binary is not available for your platform, npm will fail with a clear error during install. Test this in a shadow job before making any changes to your main pipeline.

Adoption Checklist

• Install typescript@rc locally, run tsc --noEmit, verify no regressions
• Add shadow CI jobs to your pipeline (parallel run of stable + RC)
• Compare diagnostics output from both runs for at least one week
• Verify your CI runner architecture has a pre-built binary (run tsc --version)
• Test in a feature branch or staging environment with the RC
• Document the migration plan for your team
• Schedule cutover after TypeScript 7.0 GA is released (not before RC)
• Monitor your first week on the new compiler for unexpected diagnostics

webhani partners with development teams to modernize TypeScript build infrastructure and CI/CD pipelines, unlocking faster feedback and stronger type safety practices.