Microsoft published the first preview of TypeScript 6.0 on Monday, built on the Go port of the compiler that the team announced in March 2025 and has been developing in the open since. Type checking a large codebase, the operation that has made TypeScript painful at scale, runs about nine times faster than the JavaScript implementation. On the Visual Studio Code repository, a full check dropped from 77 seconds to 8.4. On a 1.2 million line internal monorepo Microsoft used as a benchmark, it went from 4 minutes 51 seconds to 33 seconds. Editor responsiveness improves correspondingly, with the language server now answering completion requests on large files in under 50 milliseconds.
Why a port rather than an optimization
The existing compiler is written in TypeScript and runs on Node, and the team spent years extracting incremental gains from it. The remaining bottlenecks were structural: garbage collection pressure from the enormous object graphs a type checker builds, lack of real parallelism, and the cost of property access in a dynamic language on hot paths executed billions of times. None of those could be fixed without changing languages.
export async function handler(request: Request): Promise<Response> { const started = Date.now(); const upstream = await fetch(request); const headers = new Headers(upstream.headers); headers.set("x-skarvonix-ms", String(Date.now() - started)); return new Response(upstream.body, { status: upstream.status, headers, });}Go was chosen over Rust after evaluation, and Anders Hejlsberg explained the reasoning in a talk last year. The compiler's data structures are heavily graph-shaped with cycles, which fights Rust's ownership model, and the port needed to be as close to a mechanical translation as possible to preserve behavior. Go's garbage collector handles the graph naturally and its goroutines gave the parallelism the team wanted. The decision generated a great deal of online argument and the resulting performance validates it.
What the parallelism buys
The largest single gain comes from checking files concurrently, which the JavaScript implementation could not do. The Go version partitions work across available cores, with a dependency-aware scheduler that handles the cases where one file's types depend on another. On a 16 core machine, roughly 5 of the 9 times speedup comes from parallelism and the rest from the language change itself.
That also means the improvement scales with hardware in a way the old compiler never did. Developers on 8 core laptops see smaller gains than CI runners on 32 core machines, which inverts the usual pattern where CI is the slow environment. Several teams that had moved type checking out of their pre-commit hooks because it took too long are moving it back.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
Compatibility and what breaks
The team's stated goal is behavioral identity, and they have been validating against a corpus of public repositories plus Microsoft's internal code. The preview passes the existing compiler test suite with a small number of known divergences, mostly in error message wording and in the ordering of diagnostics, both of which the team considers acceptable and both of which will break tests that assert on exact compiler output.
The larger compatibility question is the API. Tools that import the TypeScript compiler as a library, which includes ESLint's TypeScript plugin, ts-morph, several bundlers, and a long tail of code generation tools, cannot call a Go binary the same way. Microsoft is shipping a JavaScript API surface backed by the Go implementation over a protocol boundary, which works and adds latency for tools making many small calls. The ESLint TypeScript team has been working with Microsoft since spring and reports acceptable results after restructuring how it batches requests.
The editor experience
The language server rewrite is the part most developers will feel. Opening a large file in a big project has historically produced a several-second wait before types resolve, and completions in deeply generic code could take long enough to be useless. In the preview, a 4,000 line file in a large project resolved in 340 milliseconds and completions returned consistently under 50.
Go-to-definition and find-all-references across a monorepo, operations that could take twenty seconds, now complete in one or two. That changes how people navigate code, and several early testers described it as the first time TypeScript tooling felt as responsive as working in a smaller language. Memory usage also dropped substantially, from around 4 gigabytes for a large project to about 1.2, which matters for anyone running multiple projects at once.
Timeline and adoption
TypeScript 6.0 stable is targeted for the fourth quarter, with the JavaScript implementation continuing as TypeScript 5.x through 2027 for anyone who needs it. Microsoft is explicit that the two will coexist for a transition period and that the JavaScript version will receive fixes but no new features after 6.0 ships.
Teams should try the preview now on a branch, primarily to find tooling that breaks. The compiler itself is likely to work; the surrounding ecosystem is where the surprises are. Anyone maintaining a tool that imports the compiler should be testing against the preview already, and the ones who are not will be the reason some teams cannot upgrade in the fourth quarter.
There is also a question about what this does to the alternatives. swc, esbuild, and oxc all built type-stripping and linting tooling partly because the official compiler was slow, and a fast official implementation removes some of their reason to exist in that specific role. Their maintainers have been sanguine about it, pointing out that bundling and transformation remain separate problems from type checking. The tool most affected is probably the set of typed linting projects, which have spent years working around compiler performance and now inherit a much faster foundation than they designed for.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
- TypeScript
