Skip to content
Angular•6 min read

Angular and TypeScript 7 (tsgo): the 10x compiler you can't use yet

The TypeScript compiler now runs between 7.7x and 11.9x faster as of July. Angular still can't use it. Version 7.0 went GA on July 8, 2026 with the compiler rewritten in Go, but Angular 22 requires TypeScript 6.0, and that's not an accident: it's a direct consequence of how deep the integration between the two projects runs.

This post explains why Angular has to wait, what the team is doing in the meantime, and the hybrid setup Microsoft recommends today if you want to start tasting TS 7 performance in your Angular projects.

TypeScript 7 in 60 seconds

The short story: Microsoft ported the TypeScript compiler from JavaScript to Go. The original announcement came in March 2025 from Anders Hejlsberg, and the goal was explicit: cut most build times by 10x. - Source: A 10x Faster TypeScript

Two years later, the promise is a number:

CodebaseTS 6TS 7Speedup
VS Code125.7s10.6s11.9x
Sentry139.8s15.7s8.9x
Bluesky24.3s2.8s8.7x
Playwright12.8s1.47s8.7x
tldraw11.2s1.46s7.7x

In production it looks like this: Slack cut its CI type-check from 7.5 minutes to 1.25 and eliminated 40% of its merge queue time. Canva went from waiting 58 seconds for the editor's first error to 4.8. - Source: same

The port was faithful, not creative: the type-checking logic is structurally identical to TypeScript 6.0. The typescript-go repo was archived on September 1, 2026 and the code moved back into the main TypeScript repo. The binary, called tsgo during the previews, is tsc again. You run npm install -D typescript and you're done.

Why Angular can't use it today

Here comes the uncomfortable part. The GA announcement says it without detours: TypeScript 7.0 ships without a programmatic API. The new API arrives with TypeScript 7.1, and it will be different from the current one. - Source: Announcing TypeScript 7.0

Why does Angular care? Because the Angular compiler is built on top of the TypeScript API. Jean Méche, from the core team, put it plainly on GitHub: "Today, the Angular compiler is a Ts.Program that makes various calls to the ts compiler APIs to build your app". No API, no Angular compiler on top of TS 7. - Source: angular/angular#61634

The second blocker is the language service. TypeScript 7 replaced tsserver with an LSP-based server, and tsserver plugins stopped working. The Angular Language Service, which type-checks your templates in the editor, is exactly that kind of plugin. - Source: Announcing TypeScript 7.0 Beta

The official matrix confirms it: Angular 22.x requires TypeScript >=6.0.0 <6.1.0. - Source: Angular version reference

Microsoft, for its part, called out the case in the GA announcement itself: workflows with specialized template type-checking "like Angular will also likely not use TypeScript 7" until the API exists. - Source: Announcing TypeScript 7.0

What the Angular team says

The official roadmap dedicates a section to it, and it's worth reading in full:

"Microsoft has spent the last year porting the TypeScript compiler to Go... Angular has perhaps one of the deepest integrations with the TypeScript compiler, which will require bigger architectural changes to support new tsgo-based workflows for both the compiler and language service. We're in the process of prototyping and exploring what this support would look like, and will deliver an Angular compiler that is compatible with tsgo."

Three readings of that paragraph: there's a public commitment (they will deliver a tsgo-compatible compiler), it covers both the compiler and the language service, and there's no date. The word "prototyping" is literal.

The work shows up in the repo. The issues asking for support (#61634 and #65492) were closed as not_planned with the explanation that the compiler had to be rewritten first. And in October 2026, PRs like #71313 showed up, running compiler tests against the NGP pipeline (the new preprocessor paving the way). That's the re-architecture the roadmap describes. - Source: angular/angular#71313

My GDE read: this will take a while. When it lands, it will be one of the deepest migrations in the framework's history, and I'd rather have a properly rewritten compiler than a rushed patch.

The hybrid setup that works today

Microsoft recommended a specific combination for Angular projects in the GA announcement: use TypeScript 7 with tsc for fast project-wide error detection from the CLI, and TypeScript 6.0 for editor support. - Source: Announcing TypeScript 7.0

The @typescript/typescript6 package exists exactly for this: it ships the tsc6 binary and re-exports the 6.0 API. With npm aliases you can keep both compilers side by side:

// package.json
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

With this, tsc (which is now TS 7) gives you the fast full-project check, tsc6 stays available for tools consuming the 6.0 API, and the editor keeps the TS 6 language service that understands your Angular templates. Mind you, this doesn't replace ng build: it's an extra safety net in CI, not the official build.

# CI: fast type check with TS 7
npx tsc --noEmit -p tsconfig.json

In a monorepo with several projects, the difference is immediate. If you already structure your workspace the way I described in monorepos with Nx, adding this global check costs you one CI line.

Get your app ready for the day it arrives

TS 6.0 exists as a deliberate bridge to TS 7. Microsoft was clear: "TypeScript 6.0 acts as the bridge between TypeScript 5.9 and 7.0". - Source: Announcing TypeScript 6.0

Angular 22 already forced you onto TS 6.0, so you're halfway there without knowing it. What's left on your side:

1. Kill the deprecations you're silencing with ignoreDeprecations. In 6.0 you can mute them; in 7.0 they're hard errors. The list: target: es5, moduleResolution: node (node10), module: amd/umd/systemjs, baseUrl, esModuleInterop: false, among others. Run your build without the flag and fix whatever surfaces. - Source: Announcing TypeScript 6.0

2. Turn on stableTypeOrdering in your CI. Type ordering changes between 6.0 and 7.0 because TS 7 parallelizes; this flag aligns 6.0's behavior with 7.0's and lets you catch differences before they matter. - Source: same

3. Run the compatibility test. Microsoft defines compatibility like this: "Practically any TypeScript code that compiles cleanly with TypeScript 6.0 (with the stableTypeOrdering flag on, and without any ignoreDeprecations flag set) should compile identically in TypeScript 7.0". A CI pipeline compiling with 6.0 under strict conditions is your insurance policy. - Source: Announcing TypeScript 7.0

4. Audit your TypeScript API dependencies. If you have internal tooling importing typescript (codemods, generators, transforms), it's built on the JS API that TS 7 doesn't have. Those tools will live on @typescript/typescript6 until the 7.1 API lands.

Final tips

  1. Don't force TS 7 into ng build. Without a programmatic API, the Angular compiler can't run on it. The hacks you'll find out there end in silent broken builds.
  2. The cheap check first. tsc --noEmit with TS 7 in CI before touching anything else. That's 80% of the benefit with 5% of the risk.
  3. Measure before celebrating. The 8-12x figures are full builds of enormous codebases. Your 200-file app already compiled in 9 seconds; your bottleneck probably lives somewhere else.
  4. Follow the roadmap, not the rumors. When the tsgo-compatible compiler gets a date, it will show up on angular.dev/roadmap before any Twitter thread.

For the full context on the Go port, with benchmarks, memory critiques and the versioning strategy, I wrote a separate deep dive: TypeScript 7 GA: the reality of the Go port.

Does your project already compile cleanly with stableTypeOrdering? Or do you have internal tooling hooked to the TS API that you'll need to rewrite? Tell me in the comments.


> More posts