TypeScript 7 Is Here: A Practical Migration Plan for the Go-Native Compiler

What Actually Shipped in TypeScript 7.0?

TypeScript 7.0 is the release the ecosystem has been anticipating since March 2025, when Anders Hejlsberg announced that Microsoft was building a native port of the TypeScript compiler and tools that would reduce most build times by 10x. Sixteen months later the promise landed. The team announced TypeScript 7.0 on 8 July 2026, describing a compiler written in Go that combines native code speed with shared-memory multithreading and typically delivers speedups between 8x and 12x on full builds.

The headline benchmarks are real codebases rather than synthetic tests. In the same announcement, type-checking the VS Code repository dropped from 125.7 seconds to 10.6 seconds, with memory use falling from 5.2GB to 4.2GB. Sentry went from 139.8 seconds to 15.7 seconds, and Playwright from 12.8 seconds to 1.47 seconds. Opening a file with an error in the VS Code codebase, the moment a developer actually waits for, went from about 17.5 seconds to under 1.3 seconds.

Early adopters reported similar gains in production. Microsoft's release post quotes Slack's CI type-checking falling from about 7.5 minutes to 1.25 minutes, Canva's time to first error in the editor dropping from about 58 seconds to about 4.8 seconds, and Microsoft's News Services team saving 400 hours a month of waiting on CI builds. Those are not marginal improvements. For a large monorepo they change how often engineers are willing to run a full check.

It is important to be precise about what this release is and is not. TypeScript 7.0 is a port, not a new language. The team says it is made to be compatible with TypeScript 6.0's type-checking and command-line behavior. Your types mean the same thing. What changed is the engine underneath, the set of configuration options it accepts, and the way other tools are allowed to talk to it.

Why Does Compiler Speed Matter More Now Than It Did Five Years Ago?

A tenfold faster compiler would have been welcome in any year, but it arrives at a moment when TypeScript has become the default language for a large share of new software. GitHub's Octoverse report found that in August 2025, for the first time, TypeScript became the most used language on GitHub, with 2,636,006 monthly contributors and growth of 66.6% year over year. The compiler is no longer a tool used by some front-end teams. It sits in the critical path of a huge amount of commercial software.

GitHub tied that growth directly to AI-assisted development. The same report argues that type systems reduce ambiguity and catch LLM errors before production, and cites a 2025 study finding that 94% of LLM-generated compilation errors were type-check failures. In other words, the type checker has quietly become one of the most important verification layers for AI-written code. Every time a coding agent proposes a change, the compiler is the cheapest and fastest judge of whether that change is even coherent.

That reframes what build time means. When a human engineer waits two minutes for a type check, they lose two minutes. When a coding agent runs an edit, check, fix loop dozens of times on a single task, a slow compiler multiplies into long wall-clock runs, higher token bills and agents that give up before converging. Hejlsberg's original announcement anticipated this, noting that new AI-powered experiences benefit from large windows of semantic information that need to be available under tight latency constraints.

For engineering leaders, the conclusion is that the TypeScript 7 upgrade is not a cosmetic version bump to schedule whenever someone has a free afternoon. It is an investment in the feedback loop that both your engineers and your agents depend on. We made a related argument in our piece on making a codebase agent-ready: fast, deterministic checks are what allow automation to be trusted.

What Breaks When You Upgrade?

Most of the breaking changes did not arrive in 7.0. They arrived as warnings in TypeScript 6.0, which Microsoft released on 23 March 2026 and described as the bridge between TypeScript 5.9 and 7.0 and the last release based on the JavaScript codebase. Version 6.0 deprecated a long list of legacy options and let teams silence the warnings with ignoreDeprecations set to 6.0. The same post is explicit that 7.0 will not support any of those deprecated options. Teams that silenced the warnings and moved on now have a backlog.

The removals that cause the most work in real projects are baseUrl, the old node or node10 module resolution, the es5 target with downlevelIteration, the AMD, UMD and SystemJS module formats, and outFile. Setting esModuleInterop or allowSyntheticDefaultImports to false is no longer supported, and the old module keyword for namespaces is gone. Any of these can appear in a five-year-old tsconfig that nobody has touched since the project was scaffolded.

Defaults changed too, and these are quieter but just as disruptive. In 6.0, strict became true by default, module defaults to esnext, target defaults to the latest ES version, rootDir defaults to the folder containing tsconfig.json, and types defaults to an empty array. A project that relied on the old permissive defaults, or on every package in node_modules/@types being picked up automatically, will see a wave of new errors that have nothing to do with the Go port and everything to do with configuration debt.

Microsoft has provided some help. The 6.0 announcement points to an experimental ts5to6 tool that rewrites baseUrl and rootDir settings across a codebase, and a stableTypeOrdering flag that makes 6.0 order types the way 7.0 does, so you can diff outputs between the two versions. The post notes that this flag can slow type-checking by up to 25% and is intended only for diagnosing differences, so use it in a migration branch rather than in everyday builds.

Which Parts of Your Toolchain Are Not Ready Yet?

The biggest practical obstacle is not your code. It is the missing compiler API. The TypeScript team states plainly that TypeScript 7.0 does not ship with an API and that it expects 7.1 to ship with a new and different one. Any tool that imports the TypeScript compiler as a library, rather than running tsc on the command line, cannot use 7.0 as it stands.

The most visible casualty is linting. When a user opened an issue asking for TypeScript 7 support on release day, a typescript-eslint maintainer replied that the project isn't compatible with TS 7 because there is no TS 7 API, and there is nothing it can do until TS 7 provides one. Type-aware lint rules are among the most valuable guardrails in a TypeScript codebase, especially for catching unsafe patterns in generated code, so this is not a dependency most teams can simply drop.

Framework tooling is in the same position. The 7.0 announcement warns that Vue, MDX, Astro and Svelte workflows will likely not yet be able to leverage TypeScript 7, and that Angular template checking is unlikely to use 7.0 yet either. If your product is built on one of those stacks, the editor and template type-checking experience will stay on the 6.x engine for now, even if your plain .ts files could compile under 7.0 today.

Help is on the way, but on a timeline you should plan around rather than assume. The TypeScript 7.1 iteration plan originally scheduled a beta on 6 October and a stable release on 24 November 2026, and in September the team said it was looking at pushing the beta about two weeks later to allow more API testing. A separate status issue notes that watch, incremental and solution builder APIs will not land as stable in 7.1. Even after 7.1 ships, each downstream tool will need its own release built against the new API, so expect a staggered rollout through the winter.

Should You Upgrade Now or Wait for 7.1?

The answer is neither a blanket yes nor a blanket no, because TypeScript 7.0 was designed to run side by side with its predecessor. Microsoft publishes a compatibility package, @typescript/typescript6, which provides a tsc6 command, and documents an npm alias for keeping 6.x installed under the typescript name. That lets tools that need the old API keep using it while your builds and CI type checks run on the native compiler.

For a plain TypeScript back end or a React front end with a modern tsconfig, the side-by-side setup is usually worth adopting now. The CI and editor gains arrive immediately, and lint keeps working against 6.x. For teams on Vue, Svelte or Angular, most of the day-to-day experience depends on tooling that cannot use 7.0 yet, so the sensible move is to finish the configuration clean-up on 6.0 and wait for the 7.1 API to propagate. For projects still carrying ES5 targets, AMD modules or heavy baseUrl aliasing, the upgrade is really a modernisation project and should be scoped as one.

Whatever the profile, there is one decision that should not wait: clearing the 6.0 deprecations. That work is required for 7.x regardless of timing, it can be done on the current compiler with no ecosystem risk, and it is the part of the migration that tends to surface surprises. Teams that do it now will be able to switch fully within days of their tooling catching up. Teams that defer it will be doing configuration archaeology under pressure later.

A Practical Five-Phase Migration Plan

Phase one is inventory. List every place the TypeScript package is consumed: tsc invocations, bundler plugins, test runners such as ts-jest, lint configuration, code generators, documentation tools and editor plugins. Separate the tools that shell out to tsc from those that import the compiler as a library. The first group can move to 7.0 today. The second group is your critical path, and its readiness, not your code, will set the date of the full switch.

Phase two is configuration clean-up on 6.0. Remove ignoreDeprecations, fix every deprecation it was hiding, make strict, types and rootDir explicit rather than relying on defaults, and replace baseUrl with explicit paths. In a monorepo, do this package by package, starting with leaf packages that nothing else depends on, so each change stays small enough to review properly.

Phase three is a shadow run. Add a CI job that type-checks with 7.0 alongside the existing 6.x job, without blocking merges. Compare diagnostics between the two, using stableTypeOrdering on the 6.x side where ordering differences make output hard to diff. Any genuine divergence is either a bug worth reporting upstream or a sign of fragile code that depends on checker implementation details. Either way, you want to find it in a non-blocking job.

Phase four is promotion. Once the shadow job has been clean for a few weeks, make 7.0 the blocking type check in CI, move developers' editors to the native language service, and keep 6.x installed only for the tools that still need the old API. Measure CI time and editor responsiveness before and after; those numbers make the business case for the remaining work. Phase five is the full switch: as typescript-eslint, your framework tooling and any internal scripts move to the 7.1 API, remove the 6.x compatibility package and the dual configuration.

Coding agents can carry much of the mechanical load here, from rewriting import paths to adding explicit types where strict mode now complains, but they need tight supervision and a fast verification loop. Our article on AI agents for large-scale code migrations covers how to structure that work so automation speeds the migration up instead of filling the review queue.

Why Do Toolchain Upgrades Stall in So Many Teams?

Nobody disputes that a faster compiler is valuable. Upgrades stall for organisational reasons. Toolchain work rarely has a product owner, it competes with features that customers can see, and the person who understands the build configuration is usually also the person most in demand for everything else. The result is the pattern visible in many codebases today: a tsconfig with ignoreDeprecations added in the spring, a ticket titled upgrade TypeScript sitting in the backlog, and a CI pipeline still paying the old build times every day.

The TypeScript 7 transition is also unusually staggered. The work arrives in three waves, the 6.0 clean-up, the 7.0 side-by-side setup, and the 7.1 tooling switch, each separated by weeks or months of waiting on the ecosystem. That rhythm is hard for a feature team to absorb. It is easy to start the work, get interrupted by a release, and come back to a branch that no longer merges cleanly.

This is the kind of work where dedicated capacity makes the difference. A small, stable team that owns developer experience and platform upgrades can run the migration as a continuous track, hold the side-by-side configuration steady while the ecosystem catches up, and switch each package as soon as its tooling is ready. The same pattern applies to the other upgrades on the 2026 calendar, from .NET end of support to Python 3.10 end of life. Upgrades that belong to everyone tend to be done by no one.

How Stepto Helps Teams Move to TypeScript 7

TypeScript is at the centre of much of the work we do at Stepto, from React and Next.js front ends to Node.js services and the AI product layers built on top of them. Our engineers in Serbia work in TypeScript every day, and toolchain upgrades like this one are part of how we keep client codebases healthy rather than a special event: configuration clean-up, side-by-side compiler setups and CI changes are routine work for the team.

A dedicated development team from Stepto can take the migration off your product engineers' plates as a defined workstream: inventory the toolchain, clear the 6.0 deprecations package by package, stand up the shadow CI job, and promote 7.0 once the diagnostics are clean. Every change goes through senior review in your repository and your pipeline, so the before-and-after build numbers are visible to you directly, not reported on a slide.

The nearshore model suits this kind of work. Our working hours overlap fully with the European business day and substantially with the US East Coast morning, so when a configuration change touches a shared package or a build pipeline, it can be discussed and merged with your team in real time. If you are also hiring for the stack itself, our guide to building a remote React and TypeScript team covers what to look for.

If your TypeScript upgrade is sitting in the backlog, or you want a second opinion on whether your stack is ready for 7.x, talk to us. We can usually tell within a short review of your tsconfig files and CI setup how much work stands between you and the faster compiler.