TypeScript 7 in production: a CI migration decision guide

Microsoft shipped TypeScript 7.0 as generally available on 8 July 2026. It is the first stable release built on the Go-native compiler that Anders Hejlsberg announced in March 2025, and the performance numbers Microsoft published with the release match the original promise: full builds typically run 8x to 12x faster, with VS Code's own 2.3-million-line build dropping from 125.7 seconds to 10.6 seconds, an 11.9x speedup. Memory use fell roughly 18% on the VS Code codebase and 26% on Bluesky's. For a Swedish enterprise team, where almost every front end and a large share of Node backends compile TypeScript on every pull request, this lands directly in your CI bill and your inner-loop wait times. It also lands with a significant gap: TypeScript 7.0 ships without a stable programmatic API, and that gap decides whether you migrate this week or wait for 7.1.

What shipped on 8 July

The compiler and language service are now written in Go and compiled ahead of time to native binaries. Microsoft's published benchmarks cover a range of well-known open-source codebases:

VS Code: 125.7s to 10.6s (11.9x faster), memory from 5.2GB to 4.2GB
Sentry: 139.8s to 15.7s (8.9x)
Bluesky: 24.3s to 2.8s (8.7x), memory from 1.8GB to 1.3GB
Playwright: 12.8s to 1.47s (8.7x)
tldraw: 11.2s to 1.46s (7.7x)

The editor story improved as much as the batch story. Opening VS Code's codebase and navigating to an error took about 17.5 seconds with the JavaScript-based language server; with the native one it takes under 1.3 seconds. Microsoft also relayed early-adopter results in the announcement: Slack reported CI type-checking going from 7.5 minutes to 1.25 minutes, Vanta reported roughly 9x speedups, and Microsoft's own News Services team estimated 400 fewer hours per month spent waiting for CI builds. Those are vendor-reported figures, but they are consistent with the benchmark spread.

Packaging is straightforward on the surface. The typescript npm package at version 7.x now delivers the native compiler. The old JavaScript-based line continues as TypeScript 6.x under @typescript/typescript6, which installs a tsc6 binary, and Microsoft has committed to maintaining both lines side by side during the transition.

What did not ship: the API gap

TypeScript 7.0 does not include a stable programmatic API. The announcement is explicit that the API arrives with 7.1. Until then, every tool that imported typescript as a JavaScript library and called into the compiler is cut off from the native line:

typescript-eslint: type-aware lint rules need the compiler API, so type-aware linting stays on TypeScript 6 for now
Webpack loaders and other build plugins that embed the compiler
Framework template type-checking: Vue, Svelte, Astro, Angular and MDX tooling all consume the API and cannot use TypeScript 7 yet

The gap bit immediately. The 7.x npm package no longer contains lib/typescript.js; the lib directory holds a shim that delegates to the native binaries. Next.js resolves TypeScript as a JavaScript module for features like typed next.config.ts, so within a day of GA, users upgrading to 7.0.2 reported that next build aborts claiming TypeScript is not installed at all. Vercel maintainers responded quickly in the project's discussion thread with a fix in progress behind an experimental flag, and documented the interim workaround: keep typescript aliased to @typescript/typescript6 for Next.js while installing the native compiler under a separate alias for direct CLI use.

The lesson generalises. If anything in your toolchain does require('typescript'), assume it breaks on 7.0 until its maintainers say otherwise. The compiler is stable; the ecosystem around the compiler API is not, by design, until 7.1.

Breaking changes you will actually hit

Beyond the API removal, 7.0 changes two tsconfig defaults that affect nearly every project:

rootDir now defaults to ./ instead of being inferred from your input files. If your emitted output layout depended on inference, set it explicitly.
types now defaults to an empty array instead of auto-including every @types package in node_modules. Global type packages such as node and jest must be listed.

{
  "compilerOptions": {
    "rootDir": "./src",
    "types": ["node", "jest"]
  }
}

A set of legacy options that were deprecated in the 6.x bridge releases become hard errors in 7.0: the ES5 target, downlevelIteration, AMD, UMD and SystemJS module output, baseUrl, classic moduleResolution, setting esModuleInterop or allowSyntheticDefaultImports to false, and Closure-style JSDoc syntax. For most codebases started in the last five years none of this applies. For a long-lived enterprise codebase, especially one that still emits AMD for a legacy portal or leans on baseUrl for path resolution, the tsconfig migration is the real project, and the compiler swap is the easy part. The 6.x line exists precisely to stage this: adopt 6.0's deprecation warnings first, clear them, then move to 7.

What a 10x compiler changes in your CI pipeline

Run the arithmetic on your own pipelines rather than trusting anyone's benchmark. The method is simple: pull the duration of your type-check and build steps from Azure DevOps or GitHub Actions for the last month, multiply by run count, and apply a conservative 8x reduction to the tsc portion only. Three effects follow from the published numbers.

Paid runner minutes shrink where tsc dominates. A type-check stage that takes six minutes on a hosted agent and runs a few hundred times a week becomes a sub-minute stage. Whether that saves real money depends on your billing model: on per-minute hosted runners it shows up directly, while on self-hosted agents it shows up as queue depth and fewer parallel agents needed. Either way the bigger win is usually feedback latency, since a PR check that returns in two minutes instead of ten changes how developers batch their pushes.

Memory headroom changes runner sizing. The 18% to 26% memory reductions Microsoft measured matter most at the top end. Large monorepos that forced you onto bigger self-hosted agents, or that hit out-of-memory failures on standard hosted runners, get breathing room. Check your peak tsc memory before assuming you can downsize, but the direction is favourable.

Elaborate caching earns less. Teams have built layered incremental-build caching, project-reference orchestration and remote build caches largely to avoid paying full type-check cost on every run. When a cold full check costs one-tenth of what it did, some of that machinery stops paying for its own complexity. Do not rip it out on day one, but re-measure: a simple cold tsc run in 7.0 may now be faster than your cache restore step was in 6.x.

Running 6 and 7 side by side

The alias pattern Microsoft documents, and that the Next.js thread converged on, lets you take the fast compiler for type-checking while every API-dependent tool keeps the 6.x package it expects:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript7": "npm:typescript@^7.0.2"
  },
  "scripts": {
    "typecheck": "tsc7 --noEmit",
    "build": "next build"
  }
}

With this layout, require('typescript') resolves to the JavaScript implementation for Next.js, typescript-eslint and friends, while your CI type-check step runs the native binary. You get most of the pipeline speedup now and defer nothing except the final cleanup, which happens naturally when 7.1 restores the API and your tools adopt it. The cost is discipline: two compiler versions can drift, so pin both and diff their diagnostics on a schedule.

Decision guide: migrate, straddle, or wait

The deciding question is not "is 7.0 stable?" It is "does anything in my repo call the compiler API?" Grep your lockfile and plugin list before you form an opinion. The compiler itself passed the RC cycle on real-world codebases; the risk lives entirely in tooling that imports typescript as a library.

Migrate fully now if your build is plain tsc or a bundler that does not embed the compiler API, you run no type-aware lint rules, and your tsconfig is free of the removed options. Typical fits: Node services, shared libraries, CLIs. Update the two tsconfig defaults and take the 10x.
Run side by side if you are on Next.js or depend on typescript-eslint's type-aware rules. Alias 6.x for the toolchain, run tsc7 --noEmit for CI type-checking, and track your framework's TS7 support thread for the switch-over moment.
Wait for 7.1 if your critical path runs through Vue, Svelte, Astro or Angular template checking, or through in-house tools built on the compiler API. There is no supported way to run those against the native compiler yet. Spend the waiting time clearing 6.x deprecation warnings so the eventual move is a version bump.

The Swedish and EU angle

Native binaries change your artifact vetting. Many Swedish enterprises route npm through a private registry mirror with security scanning tuned for JavaScript packages. TypeScript 7 delivers platform-specific native executables through npm. If your registry policy blocks packages with binaries, or your scanner ignores them, the upgrade will surface that gap. Resolve it deliberately: verify how the binaries are distributed for your platforms, extend scanning policy to cover them, and document the provenance chain the same way you would for any native toolchain component. This is routine work, but it belongs in the migration plan, not in a surprised Slack thread on upgrade day.

Toolchain governance gets a clean story. Regulated organisations, and public-sector teams buying development services through upphandling frameworks, care about support horizons. Microsoft is maintaining the 6.x JavaScript line in parallel during the transition, and staged its breaking changes as 6.x deprecations before they became 7.0 errors. That gives you a documented, incremental path to cite in an architecture decision record: adopt 6.x, clear deprecations, move to 7 when your framework tier supports it. It also gives you a defensible reason to delay, which matters when an auditor or a client asks why production still builds on the old compiler.

CI economics compound at consultancy and platform scale. For a single small repo the saved minutes are pleasant. For an organisation running hundreds of TypeScript pipelines on Azure DevOps, or a platform team billing hosted-runner minutes back to product teams, an 8x reduction in the type-check stage is a budget line. Measure it per pipeline before and after; it is one of the few infrastructure wins this year you can express in kronor without modelling assumptions.

Takeaways

TypeScript 7.0 is GA as of 8 July 2026 with 8x to 12x faster full builds and roughly 18% to 26% lower memory use on Microsoft's published benchmarks.
No programmatic API ships until 7.1. typescript-eslint type-aware rules, webpack loaders and Vue/Svelte/Astro/Angular template checking cannot use the native compiler yet, and Next.js needed an urgent fix for TypeScript detection.
Two tsconfig defaults changed (rootDir and types), and legacy options like ES5 target, AMD/UMD output and baseUrl are now hard errors.
Grep for compiler-API usage first; that single check sorts you into migrate-now, side-by-side, or wait-for-7.1.
The alias pattern (@typescript/typescript6 for tools, native tsc7 for CI type-checks) captures most of the speedup today with modest discipline.
Put native-binary vetting and registry policy on the migration checklist before the first upgrade PR, not after.