TypeScript is in Maintenance Mode: What the Go Rewrite Means for Production Systems
TypeScript 6.0 is the last JavaScript-based release. The compiler is being rewritten in Go, the JS codebase is in maintenance mode, and most open PRs will be auto-closed. What this means for production systems, tool authors, and the TypeScript contribution model.
TypeScript 6.0 is the last release built on JavaScript. The compiler is being rewritten in Go (Project Corsa), the JavaScript codebase is now in maintenance mode, and most open PRs against it will be automatically closed. For teams running TypeScript in production, this is the most significant infrastructure shift since the language’s creation.
This post breaks down what maintenance mode actually means, what changes for contributors, and what production teams should plan for.
The Announcement
On issue #62963, RyanCavanaugh (TypeScript team, Microsoft) stated:
“TypeScript 6.0 serves as a bridge release before TypeScript 7.0, and will be the last scheduled release based on the JavaScript codebase.”
“The native rewrite in Go represents an unavoidable discontinuity in development, and the logistical challenge of maintaining two codebases means we have to make some difficult decisions about work that occurred prior to the 7.0 transition. In particular, this means most PRs currently open against the JavaScript codebase won’t be merged.”
The pinned issue has 22 🚀 reactions — the community understands the rationale, even if the transition is painful for contributors with open PRs.
What “Maintenance Mode” Actually Means
The TypeScript team published explicit PR merge criteria. Only changes meeting one of these criteria will be accepted into the JS codebase:
| Criteria | Examples |
|---|---|
| Intentional 6.0 breaks / deprecations | Migration tooling, deprecation warnings |
| Critical regressions from recent releases | Worked in 5.6, broken in 5.8+, significant user impact |
| 6.0 / 7.0 behavior alignment | Compatibility fixes between JS and Go compilers |
| Crashes in 5.9+ that also repro in 7.0 | Portable fixes with no behavioral side effects |
Non-disruptive lib.d.ts changes | Type corrections, documentation additions |
Everything else — new features, general bug fixes, refactors, performance improvements — will be auto-closed. Post-6.0 patch criteria are even narrower: security issues, language service crashes, and serious regressions only.
Test-only PRs are also rejected. The team is managing sweeping baseline changes (e.g., the incoming strict: true PR) where even new tests cause merge conflicts.
Project Corsa: The Go Rewrite
The Go-based compiler is called tsgo. Key characteristics:
- Full builds 7–10× faster than the JavaScript
tscon large repositories [3][4] - Memory usage significantly reduced through native compilation and efficient parallelism
- Incremental compilation, project references, and build mode all supported — most teams can swap in
tsgowithout reconfiguring projects [4] - Language service (editor features) at parity: completions, go-to-definition, hover, signature help, formatting, find-all-references, rename, auto-imports [4]
- Strict mode enabled by default in TypeScript 7.0 [3]
- Minimum compilation target: ES2015 (ES5 targeting removed) [4]
Performance benchmarks from early adopters show typechecking time dropping by 75% in real-world codebases [3].
Why Go
Anders Hejlsberg chose Go for specific technical reasons [3]:
- Automatic garbage collection (matches the functional style of the existing TS compiler)
- Most “native-first” language available
- The existing TypeScript compiler uses a highly functional style with minimal classes — Go’s function and data structure approach is a natural fit vs. object-oriented alternatives
What Breaks: The Strada API Gap
The most significant discontinuity for tool authors is the Strada API (the legacy TSServer protocol). The native language service uses Language Server Protocol (LSP) with a substantially rewritten implementation [4]:
| Feature | Status |
|---|---|
| Core type-checking | ✅ Stable |
| Editor features (completions, definitions, etc.) | ✅ Stable |
| Incremental compilation | ✅ Supported |
| Watch mode | ⚠️ Exists but may be less efficient |
| JavaScript emit | ❌ Not fully ported |
| Downlevel compilation (pre-ES2021) | ❌ Only back to ES2021 |
| Decorator emit | ❌ Not supported |
| Strada API (TSServer) | ❌ Not supported |
JSDoc (@enum, @constructor) | ❌ Intentionally dropped |
Existing linters, formatters, and extensions that depend on the Strada API will not work with the native toolset yet. A replacement API (codenamed Corsa) is under development [4].
What Production Teams Should Do Now
1. Test the Native Preview
# CLI type-checking
npm install -g @typescript/native-preview
# VS Code extension (daily updated)
# Install: TypeScript Nightly Preview from Marketplace2. Audit Tooling Dependencies
Check whether your toolchain depends on the Strada API:
- Custom TSServer clients
- Language service plugins
- Build tools that consume the TypeScript compiler API directly
- Linters that hook into TSServer
These will need migration paths when TypeScript 7.0 ships.
3. Plan for Strict Mode by Default
TypeScript 7.0 enables strict: true by default [3]. Projects that don’t explicitly set strict in tsconfig.json may see new type errors. The TypeScript 6.0 bridge release introduces deprecation warnings to surface these early.
4. Update tsconfig.json Defaults
Several config defaults change in 7.0 [4]:
{
"compilerOptions": {
- "target": "ES5",
+ "target": "ES2015",
- "baseUrl": "./src",
- "moduleResolution": "node10",
+ "moduleResolution": "bundler"
}
}Microsoft provides a ts5to6 tool to auto-update baseUrl and rootDir in tsconfig.json [4].
The Contribution Model Shift
For contributors, the message is clear: the JavaScript TypeScript repo is effectively closed. The team explicitly directs contributors to the Go codebase (microsoft/typescript-go) for new work [1].
This is a significant shift. TypeScript has historically been one of the most welcoming large-scale open-source projects for community contributions. The JS codebase has thousands of merged community PRs. The Go rewrite resets that contribution graph.
The silver lining: the Go codebase is where all new development happens, and the team has expressed interest in community contributions there once the 7.0 launch dust settles.
Competitive Context
TypeScript 7’s native implementation puts it in the same performance tier as other high-performance JS tooling built on native compilers:
| Tool | Language | Claim |
|---|---|---|
| tsgo (TypeScript 7) | Go | 7–10× faster builds [3] |
| esbuild | Go | Bundling, not type-checking |
| SWC | Rust | Transpilation, not type-checking |
| oxc | Rust | Linter, compiler, transpiler |
TypeScript 7 is unique in offering full type-checking with native performance while maintaining complete backward compatibility with the existing TypeScript language and ecosystem.
Bottom Line
TypeScript isn’t dying — it’s being rebuilt. The Go rewrite delivers the performance that large codebases have needed for years. But the transition creates real friction: a closed contribution model on the JS codebase, a broken Strada API for tool authors, and new defaults that may surface latent type errors.
Production teams should start testing tsgo now, audit their tooling dependencies, and plan for strict mode by default. The native preview is stable enough for daily use [4] — the question isn’t whether to migrate, but when.
Sources:
[1] Transition to 6.0 Maintenance Mode · Issue #62963 — RyanCavanaugh, Microsoft
[2] TypeScript 7.0: What the Go Rewrite Means for Every Developer — DevBolt
[3] Microsoft Share Update on TypeScript 7 — InfoQ — Jan 12, 2026
[4] Microsoft Gets ‘Real’ on Native TypeScript Remake — Visual Studio Magazine — Dec 2, 2025
[5] TypeScript Go FAQ — microsoft/typescript-go