--- og_image: "/images/guides/tsgo-vs-tsc-typescript-7-go-compiler-2026.webp" title: "What is tsgo? TypeScript's Go-native compiler vs tsc" description: "tsgo is TypeScript's Go-native compiler preview. Learn what it does, how it relates to TypeScript 7, how it compares with tsc, and safe CI testing steps." date: "2026-03-15" author: "PkgPulse Team" tags: ["typescript", "tsgo", "tsc", "compiler", "performance", "typescript-7", "2026"] featured_comparison: "tsgo-vs-tsc" tier: 1 --- `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 | Question | Short answer | |---|---| | What is tsgo? | `tsgo` is the CLI for Microsoft's Go-native TypeScript compiler preview, distributed through `@typescript/native-preview`. It aims to run the same TypeScript language and type model faster than classic `tsc`. | | Is tsgo TypeScript 7? | It is the preview path for the TypeScript 7 native compiler generation. TypeScript 6 keeps the JavaScript compiler line; TypeScript 7 is the Go-native line Microsoft is working toward. | | Should I replace `tsc` with tsgo? | Not as a flag-day migration. Try tsgo beside `tsc` first, keep `tsc` for the blocking gate, and only promote tsgo where diagnostics, emit needs, editor behavior, and tooling integrations match. | | How do I test tsgo safely in CI? | Add `@typescript/native-preview`, run `tsgo --noEmit --pretty false` as a non-blocking parallel job next to `tsc --noEmit --pretty false`, collect timing and diagnostic diffs for several PRs, then decide whether a no-emit check can move to tsgo. | For the broader release path, see the [TypeScript 6 and TypeScript 7 Go rewrite guide](/guides/typescript-6-rc-new-features-go-rewrite-ts7-2026). For build-pipeline context, compare [best TypeScript build tools](/guides/best-typescript-build-tools-2026) 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 | Decision | Use tsgo / native preview | Keep classic `tsc` | |---|---|---| | Large monorepo type checks | Yes, as a measured parallel CI job first | Keep as the blocking gate until parity is proven | | Small package or app | Try it if feedback loops hurt | Usually fine until the native compiler is stable for your workflow | | Declaration emit and JavaScript emit | Test carefully against your package outputs | Keep if release artifacts must be identical today | | Watch mode | Treat as experimental/prototype behavior | Keep for daily local development when watch stability matters | | Language service / editor | Track the preview extension and opt in cautiously | Keep for team-wide editor defaults | | Compiler API, custom transformers, tool integrations | Avoid depending on preview API compatibility | Keep; this is where ecosystem assumptions are deepest | ## 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 | Area | tsgo / TypeScript native preview | classic `tsc` | |---|---|---| | Implementation | Go-native compiler codebase | JavaScript/TypeScript compiler codebase | | CLI | `tsgo` from `@typescript/native-preview` | `tsc` from `typescript` | | Current npm signal | `@typescript/native-preview` latest observed `7.0.0-dev.20260514.1` | `typescript` latest observed `6.0.3` | | Last-month npm downloads | 24,172,001 for the preview package | 813,328,241 for `typescript` | | Type checking | Main early-adoption use case | Mature default | | Build mode / project references | Listed as done in the TypeScript Go README, but still validate your graph | Mature default | | Watch mode | Listed as prototype behavior | Mature default | | Language service | Listed as in progress; preview VS Code integration exists | Mature default in editors | | Public API / custom tooling | Listed as not ready | Mature ecosystem dependency | | Best role in CI | Non-blocking or measured fast path first | Blocking fallback and release gate | ## Benchmark evidence, with the caveat that matters Microsoft's original native-port announcement reported these examples for checking public codebases: | Codebase | Approx. size | Current compiler | Native compiler | Reported speedup | |---|---:|---:|---:|---:| | VS Code | 1,505,000 LOC | 77.8s | 7.5s | 10.4x | | Playwright | 356,000 LOC | 11.1s | 1.1s | 10.1x | | TypeORM | 270,000 LOC | 17.5s | 1.3s | 13.5x | | date-fns | 104,000 LOC | 6.5s | 0.7s | 9.5x | | tRPC server plus client | 18,000 LOC | 5.5s | 0.6s | 9.1x | | rxjs observable | 2,100 LOC | 1.1s | 0.1s | 11.0x | 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: | Package / repo | Snapshot accessed 2026-05-15 | What it means | |---|---|---| | `@typescript/native-preview` | latest observed `7.0.0-dev.20260514.1`, Apache-2.0, 24,172,001 downloads in the last-month npm window ending 2026-05-12 | Preview package is actively published and visible, but versioning is still dev-preview shaped. | | `typescript` | latest observed `6.0.3`, Apache-2.0, 813,328,241 downloads in the same npm window | Classic compiler remains the ecosystem default and should stay installed during migration. | | `microsoft/typescript-go` | about 25,428 GitHub stars, 956 forks, active push observed 2026-05-15 UTC | The native compiler repo is active and public, but its README still marks API as not ready. | | `microsoft/TypeScript` | about 108,863 GitHub stars, 13,395 forks, active development | The existing TypeScript repo remains the baseline for the JavaScript compiler line. | ## Migration notes: the safe CI pattern Start with a parallel check. Do not remove `typescript` from the repo just because `tsgo` runs quickly. ```bash # 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: ```text 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](/guides/typescript-6-rc-new-features-go-rewrite-ts7-2026), [best TypeScript build tools](/guides/best-typescript-build-tools-2026), [running TypeScript directly with tsx, ts-node, and Bun](/guides/tsx-vs-ts-node-vs-bun-running-typescript-directly-2026), and [Bun Build vs Rolldown vs tsdown](/guides/bun-build-vs-rolldown-vs-tsdown-typescript-libraries-2026). ## 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](/guides/typescript-6-rc-new-features-go-rewrite-ts7-2026) - [Best TypeScript build tools](/guides/best-typescript-build-tools-2026) - [Bun Build vs Rolldown vs tsdown](/guides/bun-build-vs-rolldown-vs-tsdown-typescript-libraries-2026) - [tsx vs ts-node vs Bun for running TypeScript directly](/guides/tsx-vs-ts-node-vs-bun-running-typescript-directly-2026) - [TypeScript adoption rate in top npm packages](/guides/typescript-adoption-rate-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.