What is tsgo? TypeScript's Go-native compiler vs tsc

tsgo is the command-line entry point for Microsoft's native TypeScript compiler preview: the TypeScript 7 generation being ported to Go. It is not a new language, a new type system, or a replacement for every tsc workflow yet. If you searched for "tsgo" broadly, start with the definition below; if you are comparing tsgo vs tsc, the practical question is narrower: can you use the native preview to make type-checking cheaper while classic tsc remains your compatibility fallback?

Fast answers for tsgo searchers

For the broader release path, see the TypeScript 6 and TypeScript 7 Go rewrite guide. For build-pipeline context, compare best TypeScript build tools before changing transpilation or declaration emit.

TL;DR: what tsgo is and when to try it

Try tsgo now if tsc --noEmit is a real bottleneck in a large app or monorepo. Keep classic tsc as the required gate until your own diagnostics match. Microsoft's announcement showed roughly order-of-magnitude checking improvements across projects such as VS Code, Playwright, TypeORM, date-fns, tRPC, and rxjs, but those are announcement benchmarks, not a guarantee for your repository.

For broad tsgo searchers: install the preview package, run npx tsgo --noEmit beside your existing npx tsc --noEmit, compare diagnostics on the same lockfile and machine class, and only promote tsgo after repeated parity runs. For tsgo vs tsc searchers: tsgo is the faster native engine; tsc is still the mature JavaScript implementation with the safest API, editor, plugin, and ecosystem assumptions.

Decision matrix: quick tsgo vs tsc choice

Key takeaways

• tsgo means TypeScript's Go-native compiler preview, distributed as @typescript/native-preview with the tsgo CLI.
• TypeScript 7 is the native compiler generation. Microsoft's March 2025 roadmap says TypeScript 6 continues the JavaScript codebase while TypeScript 7 arrives when the native codebase reaches sufficient parity.
• The headline value is speed, especially for type checking. Microsoft reported order-of-magnitude improvements on several public repositories, including VS Code at 77.8s with current tsc versus 7.5s with the native implementation.
• The language does not change. The safe expectation is the same TypeScript source and type model, with compatibility gaps concentrated in implementation maturity, tooling, API, and workflow support.
• Adoption should be a side-by-side migration, not a flag-day replacement. Compare diagnostics, emit artifacts, project references, editor behavior, and CI performance before making tsgo required.

At-a-glance comparison

Benchmark evidence, with the caveat that matters

Microsoft's original native-port announcement reported these examples for checking public codebases:

Those numbers are strong enough to justify a trial, but they should not be copied into your planning as a guaranteed CI reduction. Your result depends on project references, cold versus warm cache, filesystem speed, lockfile state, machine class, framework type-generation steps, and whether your build is actually blocked by TypeScript checking rather than tests, lint, bundling, or package installs.

Package health snapshot

PkgPulse readers usually need the package-level view before changing CI:

Migration notes: the safe CI pattern

Start with a parallel check. Do not remove typescript from the repo just because tsgo runs quickly.

# Keep your existing compiler.
npm install --save-dev typescript @typescript/native-preview

# Baseline output from the mature compiler.
npx tsc --noEmit --pretty false

# Preview output from the native compiler.
npx tsgo --noEmit --pretty false

A conservative rollout looks like this:

1. Add @typescript/native-preview without removing typescript.
2. Run tsgo --noEmit as a non-blocking CI job for the packages touched by a pull request.
3. Store wall-clock time, peak memory if available, and diagnostics from both compilers.
4. Diff diagnostics for at least several CI runs across normal feature, dependency, and generated-code changes.
5. Keep tsc for declaration emit, package publishing, custom transformer workflows, compiler API consumers, or editor defaults until your specific tooling is proven.
6. Promote tsgo only for the step where it has matched tsc, usually no-emit type checking first.

Where tsgo fits in modern TypeScript stacks

Many teams already use a two-step TypeScript pipeline:

Type checking:  tsc --noEmit
Transpilation:  Vite, SWC, esbuild, Bun, tsup, tsdown, or a framework build

That split is why tsgo is attractive. If tsc --noEmit is the slow part, the native compiler can be tested without changing how JavaScript bundles are produced. If your bottleneck is framework route generation, lint, test startup, Playwright, or bundling, tsgo will not fix the slowest step.

Related planning guides: TypeScript 6 and the TypeScript 7 Go rewrite, best TypeScript build tools, running TypeScript directly with tsx, ts-node, and Bun, and Bun Build vs Rolldown vs tsdown.

Dependency risk and tooling risk

The hard part of a compiler migration is rarely the first npx tsgo --noEmit run. It is the surrounding tooling:

• package managers and lockfiles that need deterministic native binary resolution;
• generated .d.ts and JavaScript release artifacts that must be byte-for-byte safe for packages;
• test runners or bundlers that call compiler APIs rather than only running the CLI;
• IDE settings that must behave consistently across a team;
• project-reference graphs that mix packages with different tsconfig assumptions;
• custom transformers, type-aware lint rules, doc generators, or framework plugins.

If a repo publishes libraries, keep release builds on classic tsc until declaration output and downstream consumer tests are validated. If a repo only needs app-level no-emit checks, tsgo can graduate sooner.

Methodology and source-backed evidence

This refresh used the Wave 5 GSC evidence to broaden the opening answer for tsgo search intent while preserving the comparison framing that already ranks for tsgo vs tsc and tsc vs tsgo. Current status claims were checked against official Microsoft/TypeScript sources, npm registry metadata, npm downloads APIs, and GitHub repository metadata on 2026-05-15.

The benchmark table intentionally repeats Microsoft's announcement examples as official announcement benchmarks. It does not claim that every codebase will see the same speedup. The migration recommendation is based on a source-backed parity gate: same repo, same lockfile, same machine class, same TypeScript config, and repeated diagnostic comparisons before promotion.

Source-backed FAQ

Is tsgo the same thing as TypeScript 7?

Not exactly. tsgo is the CLI exposed by the native preview package. TypeScript 7 is the native compiler generation Microsoft described for the Go-port roadmap. In practice, people use "tsgo" as shorthand for trying the TypeScript 7 native compiler preview.

Does tsgo change TypeScript syntax?

No. The TypeScript language remains TypeScript. The migration risk is implementation maturity and tooling parity, not a new type system.

Can tsgo replace tsc in CI today?

It can replace a specific CI step only after your repository proves parity. The first safe step is a non-blocking tsgo --noEmit job beside the existing blocking tsc --noEmit job.

Should package maintainers use tsgo for publishing?

Be cautious. App teams can adopt a no-emit fast path earlier. Package maintainers should keep classic tsc for declaration emit and release artifacts until output, project references, and downstream tests are verified.

Why keep typescript installed if tsgo is faster?

Because the stable ecosystem still expects typescript. Editors, plugins, type-aware tools, framework integrations, and release pipelines may depend on the classic package even if tsgo handles a faster no-emit check.

Related guides

• TypeScript 6 and the TypeScript 7 Go rewrite
• Best TypeScript build tools
• Bun Build vs Rolldown vs tsdown
• tsx vs ts-node vs Bun for running TypeScript directly
• TypeScript adoption rate in top npm packages

Source notes

Official and live-data sources used for this refresh: Microsoft Dev Blogs, microsoft/typescript-go README, npm registry metadata for typescript and @typescript/native-preview, npm downloads API last-month windows, GitHub repository metadata for microsoft/typescript-go and microsoft/TypeScript, and the Wave 5 GSC export artifacts. Accessed 2026-05-15.