TypeScript 7: the TypeScript Go compiler preview
/typescript-go
TypeScript 7 is Microsoft's in-progress rewrite of the TypeScript compiler in Go, and the preview is worth installing to test against your own code today, not to replace tsc in CI yet. Type checking, JS emit, watch mode, and incremental builds already behave like TS 6.0. The catch: the language service isn't finished, so your editor still needs the JS-based tsc for now.
What is the TypeScript native port?
TypeScript 7 is Microsoft's name for typescript-go, a from-scratch reimplementation of the TypeScript compiler and language service in Go rather than TypeScript/JavaScript. The project lives in the microsoft/typescript-go repo, ships a CLI preview called tsgo, and is meant to eventually merge back into microsoft/TypeScript once it matches TS 6.0. From TypeScript 7.0 RC onward, the command is just tsc.
What works in the Go implementation
- ✓Type checking that reproduces TS 6.0's errors, message text, and error locations almost exactly.
- ✓Full JS emit and declaration emit, though declaration output intentionally differs from TS 6.0 to stay closer to the real TypeScript types.
- ✓Watch mode, build mode with project references, and incremental builds are all marked done.
- ✓JSX support and JavaScript-specific inference, including JSDoc, are complete, minus a few intentionally dropped features.
- ✓Program creation and module resolution match TS 6.0's file discovery, though not every resolution mode is supported yet.
- ✓A preview VS Code extension wires tsgo into the editor through a single settings flag.
Trying the preview build
Install the preview from npm: npm install @typescript/native-preview. That gives you the tsgo command; run npx tsgo the same way you'd run tsc. That's it. Once TypeScript 7.0 reaches RC, the binary is renamed tsc outright. If you'd rather stay inside VS Code, install the preview extension from the marketplace (TypeScriptTeam.native-preview) and add "js/ts.experimental.useTsgo": true to your VS Code settings.
Running the compiler
Once installed, tsgo is meant as a drop-in replacement: point it at a tsconfig.json and it parses, type-checks, and emits JS the same way tsc does. The project's own status table marks watch mode, build mode with project references, and incremental builds as done, so the standard tsc workflow should carry over. The README doesn't spell out the full CLI flag list, though, and it notes that tsconfig.json error messages 'may not be as helpful' yet.
Strengths
- ✓Type-checking output, errors, locations, and messages, is designed to match TS 6.0, so switching doesn't mean relearning what an error means.
- ✓Core compiler stages, parsing, type resolution, checking, JS and declaration emit, are all marked done, not just started.
- ✓Installing it is a single npm install, not a separate toolchain or config format.
- ✓A VS Code extension exists today, so you don't need to script anything to try tsgo in your editor.
What's not ready yet
- △The public API is marked 'not ready', so you can't yet build tooling against typescript-go the way you can against the current TypeScript API.
- △The language service, the part that powers editor features like autocomplete and refactors, is still 'in progress'; the README says most features are implemented but not all.
- △Not every module resolution mode is supported yet, even though program creation is otherwise marked done.
- △This is a staging repo: the README says it's expected to eventually merge into microsoft/TypeScript and be closed, so today's typescript-go issue tracker and workflow are not permanent.
- △Declaration emit is intentionally different from TS 6.0's output in places, which can surprise you if you diff generated .d.ts files against the old compiler.
Other ways to compile TypeScript
Frequently asked questions
TypeScript 7 is still a preview: the README lists the language service as 'in progress' and the public API as 'not ready', so treat it as a project to test against, not a production compiler yet.
typescript-go reimplements the same compiler and checker in Go instead of TypeScript/JavaScript, aiming to reproduce TS 6.0's type checking, errors, and emit output exactly rather than change the language itself.
Feature parity is the explicit goal, and most core pieces, parsing, type checking, JS and declaration emit, watch mode, build mode, and incremental builds, are already marked 'done' against TS 6.0 behavior in the project's own status table.
A preview VS Code extension for typescript-go is available on the marketplace as TypeScriptTeam.native-preview; enabling "js/ts.experimental.useTsgo": true in your settings switches VS Code's TypeScript support over to tsgo.
The README says typescript-go is expected to eventually merge into microsoft/TypeScript, after which the typescript-go repo and its separate issue tracker will close, with microsoft/TypeScript staying the long-term home for the project.
Speed isn't something the README states with numbers, so there's no documented benchmark to point to; the stated goal is matching TS 6.0's behavior first, with performance implied by the move to Go rather than measured in the repo's own docs.
The problem it solves
TypeScript's own compiler is written in TypeScript and runs on Node, which caps how fast type-checking and builds can get on large codebases; teams with big monorepos feel that as slow editor feedback and slow CI. typescript-go targets that specific bottleneck by re-implementing the same checker in Go, aiming for the same behavior at native-code speed instead of introducing a new type system or config format to learn.
Best use cases
- •Benchmarking your own large TypeScript project's build and type-check time against the current tsc before committing to a migration.
- •Filing real bugs against 'done' features like type checking or declaration emit, which the README explicitly asks for.
- •Trying the VS Code preview extension to see how editor responsiveness changes with tsgo powering language features that are already implemented.
- •Testing watch mode and incremental builds in a project that already uses build mode with project references, since both are marked done.
Who should try it — and who should skip
TypeScript maintainers and library authors who want faster local type-checking should install the preview now and file real bugs against it; the README explicitly invites that for anything marked 'done.' Teams with editor tooling, custom API integrations, or unusual module resolution setups should wait: the language service is still 'in progress' and the public API is 'not ready', so anything built on top of the current TypeScript API doesn't have a native-port equivalent yet.
Still deciding about typescript-go?
One click hands the question to an AI along with this page — see what it says about typescript-go.