TypeScript 7's Go Port: What the Archived Staging Repo Tells Us

A Staging Repo That Already Reached Its Goal

The first thing to know about microsoft/typescript-go is that it is closed. The README states this plainly: it was the staging repo for the TypeScript 7.0 release during the native port process, and that process is now completed. Development and discussion have moved back to the original microsoft/TypeScript repo. The README said the repo would be permanently archived in September 2026, and it is now archived. For an engineer evaluating this project, the closure is not a negative signal. It means the port reached the point where it could ship as TypeScript 7.0. But it also means you should not file issues here or expect ongoing maintenance in this repository. Any future work will happen elsewhere. The practical takeaway: treat this repo as a historical snapshot plus a distribution point for the preview package, not as a living project.

What Problem the Native Port Solves

The problem is compiler performance. The original TypeScript compiler is written in TypeScript and runs on Node.js. The native port rewrites it in Go. The announcement post, linked from the README, explains the rationale. The README's feature table shows that the port aims for exact parity with TypeScript 6.0 in type resolution and type checking, meaning the same errors, locations, and messages. That parity is the core value proposition: you get a faster compiler without changing your code or your expected output. The preview package, @typescript/native-preview, is the way to try it today. The command is tsgo, which you use as you would tsc. From TypeScript 7.0 RC onward, the command name becomes tsc.

How the Port Achieves Parity: The Mechanism

The README does not dive into Go internals, but it gives a clear picture of the architecture through the feature table. The port reimplements the entire compiler pipeline in Go: program creation, scanning and parsing, type resolution, type checking, JSX, declaration emit, JS emit, watch mode, build mode, and incremental builds. The claim is that parsing and scanning produce exactly the same syntax errors as TypeScript 6.0. Type resolution produces the same types. Type checking produces the same errors, locations, and messages. That is a strong equivalence claim. The one admitted difference in that area is that types printback in errors may display differently. For JavaScript files, declaration emit differs greatly, intentionally, to be closer to TypeScript declarations. This suggests the Go implementation is not a line-by-line transliteration but a reimplementation with the same observable behavior, except where the team deliberately changed output. For a user, this means you can expect your build output to match, but you should verify it rather than assume it.

Getting It Running: Commands and Configuration

Installation is straightforward. The README gives two commands: npm install @typescript/native-preview, then npx tsgo. You use tsgo the same way you would use tsc. For TypeScript 7.0 RC and later, the command name is tsc. There is also a preview VS Code extension on the marketplace. To enable it, you set a specific setting in your VS Code configuration: "js/ts.experimental.useTsgo": true. That setting is the only configuration key mentioned. The README does not describe any tsgo-specific command-line flags or tsconfig options. It does note that command-line and tsconfig.json parsing are done, though tsconfig errors may not be as helpful as in TypeScript 6.0. That is a practical caveat: if you rely on detailed tsconfig error messages to debug configuration problems, the native port may give you less guidance. The preview package is on npm, so you can install it in a separate project or alongside your existing TypeScript setup.

What Is Not Ready Yet: The Real Limitations

The feature table is honest about gaps. The language service, which powers editor features like IntelliSense and quick fixes, is in progress. Nearly all features are implemented, but some may not work. The README asks users to log panics but nothing else for in-progress features. More importantly, the API is not ready. If you use the TypeScript compiler API to write custom transforms, plugins, or build tools, the native port will not help you yet. The README also notes that not all module resolution modes are supported yet. Program creation uses the same files and module resolution as TypeScript 6.0, but not all resolution modes are supported. That is a concrete failure mode: if you use a less common moduleResolution setting, the preview may not resolve modules the same way. JavaScript-specific inference and JSDoc are complete but intentionally lacking some features. These are not bugs; they are deliberate scope cuts. The wrong tool scenario is clear: if you need the compiler API or full language service behavior, stay on the original TypeScript.

The Alternative: The Original TypeScript Compiler

The obvious alternative is the original TypeScript compiler, still developed in microsoft/TypeScript. The difference is in implementation language and execution model. The original runs on Node.js and is written in TypeScript itself. The native port runs as a Go binary. For most users, the observable difference is speed and memory usage, though the README does not provide benchmark numbers. The original compiler has a mature API, full language service, and years of edge-case fixes. The native port aims for parity but admits differences in error printback and JavaScript declaration emit. If you need the API or the language service, the original is the only choice. If you only need type checking and emit for a large codebase, the native port may be faster, but you must verify that your specific tsconfig and code patterns produce identical output. The README points to CHANGES.md for a list of intentional changes with respect to TypeScript 6.0. That file is the first place to look when comparing behavior.

Maintenance, Licensing, and the Archive Date

Maintenance and upgrade cost are tied to the repo's closure. Since the repo is now archived, you should not expect updates here. The npm package @typescript/native-preview is a preview; it may change or be superseded by the TypeScript 7.0 release in the main repo. The license is Apache-2.0, which permits use, modification, and distribution with conditions. The README includes a Contributor License Agreement for contributors, but that does not affect users. The repo also carries a trademark notice for Microsoft trademarks and logos, which matters if you redistribute modified versions. For upgrade cost, the main consideration is that the preview is not stable. Bugs may exist, and the README explicitly says so. If you adopt the preview, you should pin the version and test each update. The release history shows a typescript/v7.0.2 release from July 2026, which suggests active releases until the closure. After the archive, the npm package may still be installable, but you should plan to migrate to the final TypeScript 7.0 distribution from the main repo.

Editorial conclusion

Adopt the native preview if you need faster type checking and emit for large TypeScript 6.0 codebases and can tolerate missing API stability and some tsconfig error message roughness. Do not adopt it if you depend on the TypeScript compiler API, language service edge cases, or full module resolution modes. Before switching, run your existing test suite and type-check output against the preview, verify that your tsconfig features are supported, and check the CHANGES.md file for intentional behavioral differences. The repo is now archived, so track future updates in the main TypeScript repo.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes