· 6 min read ·

TypeScript 6.0 Is Here, and the Compiler Is Finally Fast

Source: typescript

TypeScript 6.0 is officially out, and the version number itself is notable. TypeScript has been on a 5.x train for a long time, shipping steady improvements without touching the major version. A major bump signals something more than new syntax features: it means the team felt ready to break things, and in this case, they broke things in ways that have been a long time coming.

The headline feature is the compiler. TypeScript 6.0 ships the Go-based rewrite of tsc as a production-ready option, following the announcement Microsoft made in early 2025 about porting the entire TypeScript compiler infrastructure to Go. Anders Hejlsberg and the team had been building typescript-go in the open, and the benchmarks they shared were striking: 10x faster cold builds, editor response times that dropped from seconds to milliseconds on large codebases.

Why Go, and Why Now

The original TypeScript compiler is written in TypeScript itself. That is a charming piece of bootstrapping, but it means tsc runs on V8 and inherits all the overhead of a JIT-compiled garbage-collected runtime. For small projects that overhead is invisible. For monorepos with hundreds of packages and thousands of source files, it is the reason CI pipelines take eight minutes to run type checking alone.

The team did not choose Rust, which would have been the fashionable systems language pick in 2025. Go was a deliberate choice for two reasons. First, Go’s garbage collector and memory model map well onto the TypeScript compiler’s existing architecture, which is heavily object-graph oriented with lots of shared references between nodes. Rewriting in Rust would have required a significant architectural redesign around ownership, not just a port. Second, Go produces fast native binaries with straightforward cross-compilation, and the TypeScript team needed to ship prebuilt binaries for Windows, macOS, and Linux without a complex build matrix.

The performance results bear this out. The typescript-go benchmarks showed the TypeScript compiler codebase itself checking in about 1.5 seconds versus 15 seconds with the old tsc. Projects like VS Code saw even larger relative gains because their type graphs are denser.

What Changes at the Compiler API Level

For most application developers, the Go compiler is a drop-in speedup. You run tsc and things are faster. For tooling authors, the story is more nuanced.

The TypeScript compiler API has historically been a TypeScript-only interface. Tools like ESLint’s TypeScript parser, ts-morph, and custom transformers all import from the typescript npm package and call into the compiler programmatically. The Go compiler ships its own interop layer that exposes a compatible API surface, but there are gaps, particularly around custom transformers and plugin hooks that reached into internal compiler phases.

If you are maintaining a tool that uses ts.createProgram or the transformation pipeline, you will want to test against the 6.0 compiler specifically. The TypeScript team has been clear that the public API contract is maintained, but some of the semi-public internals that tools relied on have changed or been removed.

The --erasableSyntaxOnly Story

Separate from the compiler rewrite, TypeScript 6.0 builds on work that started in TypeScript 5.8 with the --erasableSyntaxOnly flag. This option restricts TypeScript to syntax that can be removed by simple token stripping rather than requiring actual compilation.

The practical effect is that --erasableSyntaxOnly disallows:

  • enum declarations (which compile to IIFE objects, not erasable)
  • namespace declarations with runtime content
  • Parameter properties in constructors (constructor(private foo: string))
  • Legacy import/export syntax that produces runtime output

What remains is a TypeScript where every type annotation can be deleted character-by-character and you get valid JavaScript. No transformation logic required.

This matters because Node.js has been shipping native TypeScript support since Node 23 via the --experimental-strip-types flag, which became stable in Node 24. The way Node implements this is by running a fast type stripper (based on the amaro package, itself wrapping SWC’s TypeScript parser) rather than calling tsc. That stripper cannot handle enum compilation or namespace merging. It can only erase.

So --erasableSyntaxOnly is essentially the TypeScript team codifying the runtime contract: if you want your TypeScript to run natively in Node without a build step, stay within this subset. TypeScript 6.0 makes this flag easier to adopt and adds better error messaging when you accidentally use non-erasable syntax.

// This is fine with --erasableSyntaxOnly
function greet(name: string): string {
  return `Hello, ${name}`;
}

// This is NOT allowed -- enums require compilation
enum Direction {
  Up,
  Down,
  Left,
  Right
}

// This is NOT allowed -- parameter properties require compilation
class Config {
  constructor(private host: string, private port: number) {}
}

For new projects targeting Node 24+, enabling --erasableSyntaxOnly in your tsconfig.json is worth considering from day one. It constrains what you can write, but it also means you can run your TypeScript files directly with node --watch during development and skip the build step entirely.

Breaking Changes and Dropped Targets

TypeScript 6.0 drops the ES3 compile target entirely. ES3 was the target for Internet Explorer 8 and below, and the TypeScript team has been warning about its deprecation for several releases. If you had "target": "ES3" in your config, tsc will now error. The minimum supported target is ES5.

The --out flag, which concatenated all output into a single file and was deprecated years ago in favor of module-aware bundlers, is also removed in 6.0. If you were still using it, the migration path is to switch to a bundler.

Several deprecated type checker behaviors have been cleaned up. The strictNullChecks: false mode still exists but generates a deprecation warning, and the team has signaled it will be removed in a future release. The long-term direction is that TypeScript’s strict mode becomes the only mode.

The module and moduleResolution configuration options also see some consolidation. The older "module": "CommonJS" combined with "moduleResolution": "node" (the original pre-ESM behavior) still works but now produces a warning when the target is Node 18+, nudging users toward "module": "NodeNext" and "moduleResolution": "bundler" or "nodenext".

--isolatedDeclarations and Parallel Type Checking

One feature that arrived in TypeScript 5.5 but becomes more central in 6.0 is --isolatedDeclarations. This flag requires that every exported declaration in your code can have its type inferred without looking at other files.

// Without --isolatedDeclarations, this is fine:
export const add = (a: number, b: number) => a + b;
// TypeScript can infer the return type is `number`.

// With --isolatedDeclarations, you must be explicit:
export const add = (a: number, b: number): number => a + b;

The constraint feels annoying until you understand what it enables. With --isolatedDeclarations, tools like oxc and Rollup can generate .d.ts declaration files for each module in parallel, without needing to run the full TypeScript type checker. This is the architectural prerequisite for build tools that want to generate declarations at bundler speed rather than compiler speed.

In TypeScript 6.0, the --isolatedDeclarations mode is tighter and the error messages are better. It is still opt-in, but for library authors it is increasingly the right default.

Migration in Practice

For a typical application that has been following TypeScript’s recommended configurations, upgrading to 6.0 should be straightforward. The main action items are:

  1. Remove "target": "ES3" if it exists. Change it to "ES5" or, more likely, a modern target like "ES2022".
  2. Remove --out from any build scripts.
  3. If you are using a custom transformer or a tool that uses the TypeScript compiler API directly, test against 6.0 before upgrading in production.
  4. If you are targeting Node 24+, consider enabling --erasableSyntaxOnly and auditing your codebase for enums and parameter properties.

For library authors publishing to npm, the Go compiler’s faster declaration emit is immediately valuable. Large libraries that previously spent 30 seconds generating .d.ts files will see that drop significantly.

The Bigger Picture

TypeScript 6.0 is the result of two parallel bets the team made in 2024 and 2025. One was the Go rewrite: a high-risk, high-reward infrastructure investment that bet on compile time being a genuine user pain point worth addressing with a full port. The other was the Node.js native type stripping alignment: accepting that a meaningful portion of TypeScript’s user base wants to skip the build step and meeting them with a language subset that makes that safe.

Both bets paid off. The Go compiler is not a research prototype; it ships as the production tsc in 6.0. And --erasableSyntaxOnly gives the Node.js type-stripping ecosystem a stable target without the TypeScript language having to abandon the features that make it useful for compiled deployment targets.

TypeScript occupies a strange position in the ecosystem: it is simultaneously a language, a compiler, a type system, and increasingly a build infrastructure component that every JavaScript tool has to account for. Version 6.0 is a meaningful step toward that infrastructure being fast enough that it stops being a conversation about trade-offs.

Was this interesting?