TypeScript 7.0 Beta is Here — and It's Rewritten in Go. Here's What Actually Changed.

I've been watching the TypeScript Go port news since it first leaked, and I'll be honest — when they said "10x faster," I was ready to call marketing spin. Then I ran it on a real codebase.

It's fast. Like, uncomfortably fast. The kind of fast where you assume something must be broken.

TypeScript 7.0 Beta dropped on April 21st, and it's not your usual TypeScript release. This isn't "we added a few new types and fixed some edge cases." The entire compiler was ported from TypeScript (the language) to Go — and then they're calling the result TypeScript 7.0.

Let me break down what this actually means for you.

Wait, Why Go?

First question everyone asks. Why not Rust? Why not WASM?

The honest answer: speed of porting, not peak performance. Go's concurrency model and memory layout happened to align well with how the existing TypeScript compiler was structured. A Rust rewrite would've taken years and needed a ground-up redesign. The Go port took roughly a year, and it's architecturally identical to TypeScript 6.0's type-checking logic — same semantics, same results.

Pragmatic call. I think it was the right one.

How to Try It Right Now

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

Then run tsgo instead of tsc:

npx tsgo --version

# Version 7.0.0-beta

Note: the package is @typescript/native-preview for now. The stable release will eventually ship as the regular typescript package with the normal tsc command.

For VS Code, grab the TypeScript Native Preview extension. It's not a rough prototype — teams at Bloomberg, Figma, Slack, Google, and others have been running pre-release builds for over a year. It's been solid for months.

The Performance Is the Main Event

The Go rewrite isn't just a compiler curiosity. It unlocks parallelization that the old JS runtime couldn't do:

--checkers controls how many type-checking workers run in parallel (default: 4). Bigger codebases on beefy machines can push this higher. CI runners with limited cores should drop it down.

--builders controls parallel project reference builds — a big deal for monorepos. Combined with --checkers, it multiplies. --checkers 4 --builders 4 = up to 16 type-checkers running simultaneously.

--singleThreaded if you need to debug or benchmark against TypeScript 6 without parallelism noise.

The team reports ~10x speedups on large codebases. Based on what early adopters are saying publicly, that tracks.

Running 7.0 Alongside 6.0 (Without Chaos)

This part tripped me up at first. Here's the clean way to handle it.

There's a new compatibility package: @typescript/typescript6. It exposes a tsc6 entry point, so you can run both without naming collisions.

If you use tools like typescript-eslint that peer-depend on typescript directly, do this in your package.json:

{

  "devDependencies": {

    "typescript": "npm:@typescript/typescript6@^6.0.0"

  }

}

This aliases the typescript package to 6.0, so your existing tooling stays happy while you experiment with tsgo on the side.

Breaking Changes — The Ones That Will Actually Bite You

TypeScript 7.0 adopts 6.0's defaults as hard requirements. A lot of these were opt-in before. Now they're just on, with no escape hatch.

Defaults that changed:

• 
  strict is true by default


• 
  module defaults to esnext
  


• 
  noUncheckedSideEffectImports is true
  


• 
  types defaults to [] — your @types/node won't be picked up automatically anymore

The rootDir change is subtle but will catch you:

If your tsconfig.json sits outside your src/ folder (pretty common), you need to add this:

{

  "compilerOptions": {

    "rootDir": "./src"

  },

  "include": ["./src"]

}

The types change will also catch you:

{

  "compilerOptions": {

    "types": ["node", "jest"]

  }

}

List every @types package your project needs explicitly. No more implicit globals from everything in your node_modules/@types.

Things that are just gone:

• 
  target: es5 — not supported


• 
  moduleResolution: node / node10 — use nodenext or bundler
  


• 
  module: amd, umd, systemjs, none — gone


• 
  baseUrl — use paths relative to the project root instead


• 
  downlevelIteration — gone

If you're still on any of these, migrating to TypeScript 6.0 first will make the 7.0 transition cleaner.

JavaScript Support Got a Full Rethink

This one flew under my radar until I read the details. TypeScript 7.0 rewrites how .js files are handled — moving away from Closure-style JSDoc support toward patterns consistent with .ts files.

Key changes:

• 
  @enum is no longer special — you need @typedef instead


• 
  @class on a function doesn't make it a constructor anymore — use a class declaration


• Closure-style function syntax like function(string): void is dropped — use (s: string) => void
  


• 
  values can't be used where types are expected — use typeof someValue
  

If you have a pure-JS codebase that relied on TypeScript's JSDoc inference, check the CHANGES.md before upgrading.

What's Still Missing

The beta label is real, but it's not hiding a disaster — it's flagging a few known gaps:

• No stable programmatic API yet (that's TypeScript 7.1 at earliest)


• 
  --watch mode is less efficient than it'll eventually be


• Some VS Code features are still coming: semantics-enhanced highlighting, more granular import commands


• Declaration file emit from .js files is still being finished

If you depend on the TypeScript compiler API for custom tooling, wait for 7.1. For everything else — type-checking in CI, editor experience, build times — 7.0 Beta is ready.

My Take

The Go port is a genuinely impressive engineering decision. Not the most glamorous language choice, not the theoretical peak, but it shipped in about a year and already works on multi-million line codebases.

The breaking changes are real, but most of them were coming anyway. TypeScript 6.0 gave everyone a year to see them coming. If you've been keeping up with releases, 7.0 should feel like a minor migration with a huge performance payoff.

If you haven't touched your tsconfig.json in two years and still have moduleResolution: node in there... you have some cleanup to do. But that cleanup was overdue regardless of whether TypeScript 7 existed.

Try it today:

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

npx tsgo --version

Run it on something real and let the speed be someone else's excuse to finally upgrade the old config.

Found issues? The team wants feedback at the microsoft/typescript-go issue tracker — not the main TypeScript repo. That distinction matters during the beta.