TypeScript 7 RC ports the compiler to Go for much faster faster builds

The TypeScript 7 release candidate is out, and it's more than your usual "yet more syntax." Microsoft has ported the entire compiler to Go, promising TypeScript developers something we almost never get: serious real-world speed. The team expects the native implementation to reduce most build times by much faster, with much snappier editor feedback — the kind that makes large projects feel light again. This port isn't technical theater; it's changing the game for anyone shipping TypeScript at scale.

If you're wondering whether to bet early on TypeScript 7 or how the Go port changes your workflows, here's why these speed gains actually stick, how to use the new compiler today, and what it means for the future of TypeScript development.

What is the TypeScript 7 compiler port to Go?

Until this release, the TypeScript compiler was itself written in TypeScript — compiling down to JavaScript, then running as a Node.js process. This approach worked but imposed hard caps: running inside a JS VM meant fundamentally serialized execution, thread limits, and a reliance on V8's garbage collector.

TypeScript 7 isn't so much a "rewrite" as a port. Microsoft took the live codebase — the type checker, inference logic, and emit path developers rely on — and moved it into Go. They did not start over. They transcribed each piece methodically to preserve the behavior you already depend on. The staging repo for the native port states it plainly: this was the working repo for the TypeScript 7.0 release during the native port process, and that process is now completed, with ongoing work continuing in the main TypeScript repo.

For developers, this is nearly invisible at the source level. Write TypeScript as before. The repo's feature-parity table reports program creation, parsing, type resolution, type checking, JSX, declaration emit, watch mode, and incremental builds all done with the same errors and types as the previous generation. One caveat worth knowing: legacy and deprecated compiler flags may behave differently under the native compiler, so review your tsconfig for long-deprecated options before switching.

How to try the native compiler today

You don't need to wait for a stable release to feel the difference. Microsoft ships a preview build on npm:

npm install @typescript/native-preview
npx tsgo # Use this as you would tsc.

For TypeScript 7.0 RC and later, the command name is tsc — the preview binary was the bridge, the release candidate folds it into the name you already type. There's also a preview VS Code extension you enable with one setting:

{
  "js/ts.experimental.useTsgo": true
}

Fair warning, straight from the repo: the preview is still a work in progress and not yet at full feature parity, so check the parity table before assuming an intentional change, and file issues for anything that looks like a regression. Early adopters on small-to-medium projects are the ideal testers; keep your JS-based toolchain as the fallback in CI until you've validated your repo.

Why does Go make it this much faster?

Three compounding factors, all consequences of leaving the JS VM behind:

• Native code instead of interpreted bytecode. A compiled Go binary doesn't pay the JIT warmup cost or the overhead of running a compiler on top of a runtime designed for UI scripting. Startup alone gets dramatically cheaper, which is why editor startup is one of the headline wins.
• Real parallelism. Type checking large programs involves work that can be split across cores. Go's concurrency model lets the native compiler use the whole machine instead of bottlenecking on a single thread.
• Lower, more predictable memory use. Microsoft's announcement post explicitly targets substantially reduced memory usage alongside the much faster build-time goal. No GC pauses from a host runtime means fewer of the random editor stalls developers currently blame on "a big project."

The announcement frames the motivation well: as codebases grow, so does TypeScript's value — but the old compiler couldn't scale to the very largest codebases, forcing developers to choose between reasonable editor startup and a complete view of their source. The native port removes that tradeoff.

What changes for editors, CI, and AI tooling?

Editors. Faster startup, faster rename/find-all-references/go-to-definition, and a language service that doesn't degrade as the monorepo grows. If your editor currently takes minutes to "warm up" on a large workspace, this is the single biggest quality-of-life upgrade in years.

CI pipelines. Type checking is often the slowest gate in a TypeScript CI job. A near-order-of-magnitude cut in tsc time shortens every pull-request cycle. Faster gates mean smaller batches, quicker reverts, and less context-switching while developers wait on green checks.

AI coding assistants. This one matters more than it looks. Microsoft's announcement explicitly notes that AI-powered experiences benefit from large windows of semantic information delivered under tight latency constraints. Agents that lean on the language service for types, references, and rename safety get faster, more accurate answers from a native core. If you're building agent-friendly repos, pair the faster compiler with a codebase layout agents can navigate — see our guides to an agent-readable repository structure and Cursor rules for Next.js.

What does this mean for the future of TypeScript development?

This is a foundational shift for TypeScript, and not just in superficial speed. The decision to port to Go opens several doors:

• Further speed potential: Now that the performance ceiling is native code and parallelism, expect the core team (and the broader open-source community) to drive even bigger optimizations in future releases, from smarter compile caches to experimental incremental compilers written for multi-core workloads.
• Broader tooling integrations: IDEs, continuous integration pipelines, and new TypeScript-adjacent tools can count on consistent and predictable speed. No more fighting the randomness of Node/GC pauses. Expect faster, CI-native plugins and entirely new classes of language tooling built on the Go core.
• Expanded contributor base: Go is a widely taught — and inviting — systems language. This may open TypeScript's internals to a new wave of contributors, unblocking core compiler contributions that were previously limited to experts in JS self-hosting.
• Shared code across platforms: Teams shipping the same TypeScript on web and mobile feel compiler pain twice. If that's you, our same-component web-mobile architecture guide shows how to structure the shared code that a faster compiler will now chew through in seconds.

Takeaway: the Go port doesn't just dump baggage; it sets the floor for platform-level speed and opens the architecture for serious, systems-grade improvements in TypeScript's future.

Closing: TypeScript finally grows up

For years, TypeScript felt like the language that tried to match JavaScript's flexibility but paid for it in every long build and sluggish code navigation. TypeScript 7, with its natively compiled Go core, is the real break. Fast builds and near-instant editor feedback aren't a footnote — this is how scale-obsessed teams actually move fast. If you haven't tried the preview, now is the time: install it, point it at your biggest package, and time the difference yourself. The speed is real. The future-proofing is real. And you can try it today.

Want a kit that already assumes a fast, modern TypeScript setup? Browse the OTF templates.

Sources

• microsoft/typescript-go on GitHub — staging repo, completed port status, @typescript/native-preview usage, feature-parity table (verified live 2026-09-06).
• A much faster faster TypeScript — Microsoft DevBlogs — much faster build-time goal, memory reduction, timeline (verified live 2026-09-06).