TypeScript 7 Beta and tsgo: Treat the native compiler as a migration project

Tech
A migration diagram for validating TypeScript 7 tsgo beside TypeScript 6 tsc across CI, editors, build APIs, and rollout gates
The practical path is to run tsc and tsgo side by side, then promote tsgo only after the differences are understood.

The first question after the TypeScript 7.0 Beta is not “how fast is it?” It is “which parts of our TypeScript infrastructure can safely move?” Microsoft’s beta introduces a Go-based native foundation, published for now as @typescript/native-preview@beta with the tsgo command. That packaging is the important operational detail: teams can run the new compiler beside TypeScript 6 instead of replacing their default tsc path immediately.

TypeScript is more than a compiler package. In many teams it is the CI quality gate, the editor language service, the declaration-file generator, part of code generation, and a dependency of internal tools that read AST or type information. A faster compiler can change developer workflow, but only if the migration is measured rather than assumed.

What changed

On April 21, 2026, Microsoft announced TypeScript 7.0 Beta. The release is based on a methodical port of the TypeScript implementation to Go, with the goal of preserving TypeScript 6.0 semantics while improving command-line and editor performance. The beta can be installed with npm install -D @typescript/native-preview@beta, then run with npx tsgo.

The beta also makes side-by-side validation explicit. The stable TypeScript 7 path is expected to return to the typescript package and the tsc command later, but the preview uses a separate package and binary so teams can compare diagnostics, declaration output, project references, and editor behavior without creating ambiguity around which compiler is running.

Why it matters

In a large TypeScript codebase, type-check latency is not just idle time. It affects pull-request throughput, CI queue pressure, editor startup, monorepo validation, and the amount of semantic context available to AI coding tools. If native TypeScript makes full checks cheap enough to run more often, teams can reduce the habit of skipping local type checks and waiting for CI to catch problems.

But faster does not mean risk-free. The typescript-go README marks the programmatic API as not ready, watch mode as prototype, and LSP work as still in progress. Its CHANGES document also lists intentional differences around JavaScript, JSDoc, declaration emit, CommonJS, and expando patterns. A mostly modern .ts codebase and a legacy JS-with-JSDoc package should not use the same rollout plan.

Community and practitioner signals

The official announcement says the beta has already been tested on large codebases inside and outside Microsoft. At the same time, current work in the typescript-go repository continues around language-service details such as file watching, UTF-8/UTF-16 position handling, and LSP requests. That is the practical signal: the compiler path is ready enough to evaluate seriously, while editor behavior and tool integration deserve their own gates.

Expected impact on development and operations

  • CI: Keep tsc as the release gate at first. Add tsgo as a non-blocking job and promote it only when differences are zero or explained.
  • Editors: Trial the TypeScript Native Preview extension with one squad or one repository before changing the wider team default.
  • JavaScript and JSDoc: Review CHANGES.md before testing repositories with old CommonJS, Closure-style JSDoc, expando declarations, or JS-based declaration emit.
  • Build tooling: Keep tools that depend on the TypeScript compiler API on the TypeScript 6 path until the API story is stable.
  • Monorepos: Validate project references, incremental builds, and watch workflows against the real package graph rather than a small sample project.

A rollout checklist

  • Record the current tsc --noEmit time, diagnostics, and declaration output for a representative repository.
  • Install @typescript/native-preview@beta and add npx tsgo --noEmit as a separate CI job.
  • Compare not only error counts, but also locations, JSDoc-derived types, .d.ts output, and project-reference behavior.
  • Enable the VS Code preview for a limited group and collect issues for rename, find references, completions, and diagnostics.
  • Inventory internal tools that import typescript or call the compiler API. Keep those on the old path for now.
  • Define promotion criteria before the rollout: no unexplained CI delta, acceptable editor behavior, and a documented rollback path.

Risks and counterarguments

The strongest counterargument is that this is still beta. That is correct, and it is exactly why the migration should start as observation, not as a default switch. Large repositories need time to uncover edge cases. A non-blocking comparison job gives the team evidence before the stable release forces a decision.

The second risk is over-reading performance claims. Microsoft’s measurements and preview experience are useful signals, not a guarantee for every repository. If your build is dominated by bundling, tests, code generation, or cache misses, faster type checking may improve only part of the pipeline.

The third risk is legacy JavaScript. The native port intentionally simplifies some JS and JSDoc behavior. Teams that rely on those patterns should budget migration work before treating tsgo as a drop-in replacement.

Bottom line

TypeScript 7 Beta is not merely a faster compiler announcement. It is a chance to re-measure the type infrastructure that holds modern front-end and full-stack codebases together. The best next step is conservative but active: run tsgo beside tsc, collect differences, trial the editor path, and separate compiler-speed wins from API and language-service readiness.

Sources

다른 글