Looking back at the TypeScript 6.0 Beta announcement from February 11, 2026, the most striking line is almost buried in the introduction: this is intended to be the last release based on the current JavaScript codebase. After fourteen years of TypeScript compiling TypeScript, that sentence closes an architectural chapter that most developers never thought much about.
The self-hosted nature of the TypeScript compiler has always been a point of pride for the project. Writing a compiler in the language it compiles is a rite of passage, a proof of substance. Since 2012, every type check you ran, every squiggly line in VS Code, every .d.ts file emitted, came from TypeScript code running through V8. TypeScript 6.0 is the end of that arrangement.
What Comes After JavaScript
Microsoft announced the Go port of the TypeScript compiler in March 2025, with the repository visible at microsoft/typescript-go. The project is a native port, not a reimplementation with different semantics. The goal is identical type-checking output with dramatically better performance.
The numbers that have come out of early benchmarks are serious. Cold builds that previously took minutes drop to seconds. Type checks that ran for 90 seconds in the JavaScript compiler run for around 9 seconds in Go. The consistent figure cited across multiple sources is a 10-15x improvement on build times, with memory usage dropping proportionally as well.
The reason Go was chosen over Rust or another systems language comes down to pragmatics. Go’s garbage collector is well-suited to compiler workloads where you allocate many short-lived objects during a type-checking pass. Rust would have required a more invasive rewrite to satisfy the borrow checker. Go also offers real native threads and structural concurrency, which eliminates one of the core limitations of the Node.js-based compiler: V8 is single-threaded, and TypeScript’s language server has always been constrained by that.
Parallel file checking, which the Go compiler enables, is particularly valuable for large monorepos where the existing compiler serializes work that could run concurrently. The isolatedDeclarations feature, which became stable in TypeScript 5.5, was explicitly designed with this parallel future in mind. It requires explicit type annotations on exported declarations so that .d.ts files can be generated per-file without needing to see the rest of the program.
The Cleanup That 6.0 Brings
Beyond the compiler backend story, TypeScript 6.0 does significant housekeeping that the team has deferred for years. Some of these removals will cause real migration pain for existing projects.
ES3 and ES5 are gone as --target options. This is overdue. ES5 was the universal baseline for the browser era, but in 2026, shipping ES5 output means you are either targeting browsers that represent a negligible fraction of traffic or you have a policy requirement that deserves its own toolchain discussion rather than TypeScript’s built-in downleveling.
The experimentalDecorators flag and its companion emitDecoratorMetadata are also removed. These flags powered the decorator patterns that Angular, NestJS, TypeORM, and a generation of TypeScript frameworks were built on. They predated the TC39 decorator proposal by years and diverged from it significantly. The standard decorator proposal has been available since TypeScript 5.0, and the migration path has been documented, but a substantial amount of existing code still relies on the old behavior.
Here is what the new standard decorator approach looks like for a method decorator that records metadata:
function logged(target: any, context: ClassMethodDecoratorContext) {
const methodName = String(context.name);
context.addInitializer(function () {
const meta = context.metadata as Record<string, string[]>;
meta.loggedMethods ??= [];
meta.loggedMethods.push(methodName);
});
}
class Service {
@logged
fetch(url: string): Promise<Response> {
return globalThis.fetch(url);
}
}
console.log((Service as any)[Symbol.metadata]);
// { loggedMethods: ['fetch'] }The new model uses Symbol.metadata, which is part of the finalized TC39 decorator metadata proposal. The old emitDecoratorMetadata approach emitted Reflect.metadata calls that depended on a polyfill and encoded TypeScript-specific type information in a way the standard never adopted. Removing it is correct, but Angular projects in particular will need careful migration planning.
Module resolution also gets cleaned up. The legacy "moduleResolution": "node" setting, which does not understand ESM semantics, package exports fields, or .mts/.cts extensions, is deprecated. The node16 and nodenext options have been the right choice for Node.js projects for a couple of years, and 6.0 stops pretending otherwise.
The Ecosystem Impact Nobody Is Talking About Enough
For application developers, TypeScript 6.0 is a tsconfig.json cleanup exercise with some decorator migration work. For tool authors, it is more complicated.
The TypeScript compiler API, exposed through the typescript npm package, is what powers tools like ts-morph, typescript-eslint, language servers, code generators, and documentation tools. The Go compiler will eventually expose a different API surface. Microsoft has signaled they will maintain a JavaScript compatibility layer for some period, but the long-term direction is a Go-native API.
This matters because a lot of the TypeScript ecosystem’s tooling is built on ts.createProgram, ts.LanguageService, and related APIs. These are not small utilities; tools like typescript-eslint use them to provide type-aware linting rules that require full program analysis. Replicating that functionality against a Go-native API will require significant work from maintainers who are mostly volunteers.
The language server situation is worth watching separately. The 10-15x build speedup is compelling for CI and local builds, but interactive language server performance has a different optimization target. What matters for developer experience is not average throughput but tail latency on incremental operations: how long does autocomplete take after you type a character, how quickly does a go-to-definition resolve. The RC period for 6.0 is partly about validating behavior parity under real editing conditions before the Go implementation takes over.
The Isolatability Shift
One quiet but important change in 6.0 is isolatedDeclarations becoming a first-class signal in the language server and project references infrastructure. When this flag is enabled, each file in your project must be self-describing: every exported symbol needs an explicit type annotation so the compiler can generate its .d.ts without type inference across file boundaries.
This is a meaningful restriction on coding style. TypeScript’s type inference is one of its most valued features, and requiring annotations on all exports feels like a step backward to developers accustomed to writing export const foo = computeSomething(). But it is the constraint that makes parallel declaration emit possible, and parallel declaration emit is what makes 10-15x faster builds achievable on large codebases.
The isolatedDeclarations documentation frames this as opt-in, and 6.0 does not make it mandatory. For projects that want to get ahead of the Go compiler’s performance capabilities, enabling it now alongside TypeScript 6.0 is worth the annotation overhead.
A Fourteen-Year Milestone
TypeScript’s self-hosted compiler was a piece of software engineering credibility, but credibility does not run your CI pipeline. The V8 ceiling was real. Large TypeScript codebases at companies like Google, Microsoft, and others have been fighting compile time for years with project references, incremental builds, and transpileOnly mode in ts-loader. The Go rewrite addresses the actual constraint.
TypeScript 6.0 is not the exciting release. The exciting release is whatever comes after it, when the Go compiler ships as the default and a decade of accumulated tooling catches up. What 6.0 does is close out the JavaScript implementation correctly: removing the features that depended on transformation rather than erasure, aligning with finalized TC39 proposals, and setting the module resolution baseline that the new compiler will carry forward.
The beta is available now via npm install -D typescript@beta. For most projects, the migration surface is manageable. The real work is watching what happens to the ecosystem tooling over the next year as it adapts to a compiler that no longer runs in Node.js.