The official rewrite changes the calculation
TypeScript 7 is not another fast parser that accepts TypeScript syntax and leaves type checking elsewhere. Microsoft is rewriting the compiler and language service in Go, with the stated destination being the main TypeScript repository. That makes this project unusually consequential: if the rewrite succeeds, teams do not have to choose between official TypeScript behavior and a native implementation.
The current repository already covers the main compiler path. Its status table marks parsing, type resolution, type checking, JavaScript emit, declaration emit, watch mode, project references, and incremental builds as done. Microsoft's definition of done is careful, meaning the team knows of no major deficits, not that bugs are impossible. The language service is still in progress, and the API is explicitly not ready. Those two lines should determine how adventurous you can be.
For ordinary evaluation, the package name and command keep the barrier low. Install @typescript/native-preview, then run npx tsgo as you would run tsc. The README notes that the command becomes tsc for the 7.0 release-candidate line and later. VS Code users can install Microsoft's preview extension and opt into the experimental native service with one setting. You do not need a Go toolchain merely to see whether your project checks.
Compatibility is close, not identical
The status table says core compiler stages target the same files, types, errors, and emitted output as TypeScript 6.0, but every claim has qualifications. Not all module resolution modes are supported. Configuration errors can be less helpful. Printed types in diagnostics may differ. JavaScript declaration output is intentionally different. The separate change document is essential reading because some differences are design decisions, not defects waiting to be fixed.
The biggest migration risk sits in older JavaScript rather than conventional .ts files. The Go implementation drops several Closure-flavored JSDoc forms, constructor-function inference, and assorted expando and CommonJS patterns. It also changes offsets from UTF-16 to UTF-8 inside the API. Modern JavaScript using modules, classes, and current syntax is the stated priority. A mature codebase that treats JSDoc as a type system, generates declarations from JavaScript, or depends on exact node positions needs a dedicated compatibility pass.
This distinction is healthy. Preserving decades of accidental behavior forever would weigh down the new compiler. It also means that the correct adoption test is your repository, not a successful compile of a small demo. Compare diagnostics, declaration files, generated JavaScript, watch behavior, project references, and incremental rebuilds. Run both compilers in CI long enough to catch changes that only appear after build information has been reused.
The missing API is a hard boundary
Compiler and editor extension authors should wait or prototype with care. The README labels the API not ready, and Go cannot load third-party JavaScript directly into the server process the way TS Server plugins do today. Microsoft is discussing an IPC-based API and TypeScript client library instead. The design aims to expose read-only program and type-checker capabilities while giving framework language servers a way to work with virtual files. It is active design work, not a finished replacement contract.
That matters beyond niche tooling. Vue, embedded languages, custom refactors, code generators, and analysis products often reach into the TypeScript compiler or language service. Their migration may involve new process boundaries, content mapping, and module-resolution coordination. If your tool calls ts.createProgram or installs a TS Server plugin, the easy npm setup does not describe your actual porting cost.
Application teams are in a better position. They can treat the compiler as an executable and evaluate it without committing to the unfinished API. Even then, editor testing deserves its own track. The LSP is nearly implemented according to the README, but nearly is not parity. An open report describes high CPU use on a low-end laptop, and another documents severe memory growth in a particular empty-workspace arrangement. These reports are specific cases, not proof that every workspace suffers, but they make resource monitoring part of a responsible trial.
Fast-moving code needs production guardrails
The issue tracker shows why a fallback still matters. One open report describes a repeatable nil-pointer panic in version 7.0.2 and a nightly build during an incremental rebuild that prints declarations. A clean check passes in that case, while reuse of the build-information file triggers the crash. That is exactly the kind of defect a toy benchmark misses and a real CI soak catches.
Project health itself is excellent. The repository was pushed on August 11, 2026, and issues and pull requests were being updated the same day. The latest release, 7.0.2, was published July 8. GitHub lists 285 open issues and pull requests combined, a substantial queue attached to an extremely active migration rather than a quiet backlog. More than 26,000 stars show attention, although activity and Microsoft's ownership are better health signals than popularity alone.
Documentation is concise where the adoption decision starts and detailed where incompatibility gets tricky. The README gives installation, editor setup, feature status, definitions, and the eventual repository move. CHANGES.md records intentional behavioral differences with concrete replacements. What is missing is the settled API guidance that extension authors need, because the design itself is unfinished.
Who should switch now
Large TypeScript applications should test TypeScript 7 now. The cost of a parallel CI job or an opt-in editor experiment is small, and early testing reveals whether your particular module layout, generated declarations, or JavaScript conventions collide with the rewrite. Teams starting a new conventional TypeScript application can be more aggressive, provided they pin versions and retain an escape route.
Do not confuse an official release with universal compatibility. Keep TypeScript 6 available, compare artifacts rather than only exit codes, and test warm incremental builds as well as clean ones. Tool authors should follow the API discussion before promising support. TypeScript 7 is already real enough to evaluate seriously, but its best role today is a closely watched successor running beside the dependable implementation it intends to replace.