The repository has completed its one job
TypeScript Go was the workshop for Microsoft's native port of TypeScript. The project rebuilt the compiler and language-service work in Go, with a preview package named @typescript/native-preview and a tsgo command. Its feature table says parsing, type checking, JavaScript output, watch mode, project references, and incremental builds are believed done against TypeScript 6.0 behavior. The language service is still marked in progress, and the public API is marked not ready.
That description now needs a large qualifier: this repository is closed for ongoing work. Its README says the native-port process is complete, directs development and discussion to microsoft/TypeScript, and says this staging repository will be permanently archived in September 2026. The last push was August 24, 2026, but the only open issue is an August notice titled "This Repo Has Moved!" Active recent commits therefore do not make this an active destination for new adoption.
The distinction matters because 26,227 stars can make the repository look like a current standalone compiler project. It is better read as a completed migration workspace. The July 8 release tagged typescript/v7.0.2 is useful history, while current TypeScript releases, bug reports, and contributions belong in the original repository.
The preview is easier than building the source
For someone testing the compiler, the README offers a short route: install @typescript/native-preview, then run npx tsgo as you would run tsc. VS Code users can install the native preview extension and set js/ts.experimental.useTsgo to true. The command is transitional, since TypeScript 7.0 RC and later use tsc.
That quick start is about consuming a packaged preview. It is not a contributor guide for this 562.9 MB source tree. The main README does not list the toolchains or commands needed to build and test the checkout. Our run makes one missing prerequisite plain: both source tasks invoke Go. A developer arriving with only Node 22 can install the JavaScript dependencies but cannot compile or test the port.
The repository also contains 136,830 files and about 5,668,799 lines of source in a workspace layout. Those figures describe a substantial compiler staging tree, not a small replacement binary that most application teams should vendor or fork. If you only want TypeScript 7, use the supported package path from the active TypeScript project.
What happened when we ran it
Our sandbox installed 437 npm packages in 49 seconds, leaving 453 MB of dependencies on disk. Installation completed successfully. The build failed 8 seconds later when the task runner started go build and received spawn go ENOENT, which means the executable was unavailable in that environment.
Tests reached the same boundary in 6 seconds. The task attempted go test ./... --timeout=45m, then stopped with spawn go ENOENT. The log does not show a compiler defect or a failing assertion, so it would be wrong to call this a TypeScript correctness failure. It shows that a fresh Debian container based on the supplied Node image did not contain a required system tool, and the main README did not prepare a source builder for that requirement.
The npm audit found 7 known high-severity vulnerabilities, with zero findings at the other listed severities. That result applies to the dependency tree we installed at commit 89d5d5b. Given that the repository is moving into archival status, anyone retaining this checkout should decide whether those dependencies need remediation or whether moving to the active repository is the cleaner answer.
Feature parity still has explicit boundaries
The feature table is refreshingly specific about what "done" means: the maintainers believe no major deficits remain and invite bug reports. It does not promise byte-for-byte sameness everywhere. Error type printouts may differ, tsconfig errors may be less helpful, JavaScript declaration emit intentionally differs, and not every module-resolution mode is supported.
Editor and tool authors face the larger limits. The language service is only nearly complete, while the API is not ready. Those labels are enough reason to avoid building a new integration against this repository's internal shape. An application team evaluating compile behavior can try the preview, but an extension author needs the current contracts and issue tracker in microsoft/TypeScript.
The README points readers to CHANGES.md for intentional differences from TypeScript 6.0. That is essential reading for migrations because a native rewrite can be useful and still behave differently at the edges. Do not infer compatibility from the completed rows alone.
Use the destination, keep this for archaeology
Microsoft has removed the hardest strategic uncertainty: the Go port is part of TypeScript's future, but this repository is not its permanent home. New bug reports here would land beside a single migration notice, and new contribution work would have to move again when archival arrives in September 2026.
Use microsoft/TypeScript for current releases and development. Choose SWC when the job is fast transformation without TypeScript's own checker, or Oxc when you want modular parser and linter components. Keep typescript-go bookmarked when a preview regression, old commit, or design decision requires the staging history. That is a narrow use, but it is the honest one.