The headline is native speed
On July 8, Microsoft shipped TypeScript 7.0 to general availability, and the release is defined by a single fact. The compiler and language service are now a native program written in Go rather than a JavaScript codebase running on Node. Daniel Rosenwasser, the principal product manager for TypeScript, announced the availability of what Microsoft describes as a 10x faster native port. The speedup comes from three sources working together, namely native machine code, shared-memory multithreading, and a set of new optimizations that the previous single-threaded JavaScript implementation could not exploit. The result reshapes what large TypeScript projects can expect from their build and editor tooling.
The benchmark numbers are concrete and drawn from real codebases rather than synthetic tests. Type-checking the VS Code codebase fell from 125.7 seconds on TypeScript 6 to 10.6 seconds on TypeScript 7 at default settings, an 11.9x improvement. Sentry dropped from 139.8 seconds to 15.7, Bluesky from 24.3 to 2.8, and Playwright from 12.8 to 1.47. Microsoft characterizes the typical full-build speedup as between 8x and 12x. Memory consumption also improved, falling between 6 and 26 percent across the measured projects. For teams whose continuous integration spends minutes on type-checking, the compounding effect across every pull request is substantial.
How Microsoft preserved compatibility
The most important engineering decision was to port rather than rewrite. Microsoft translated the existing TypeScript implementation into Go methodically, keeping the type-checking logic structurally identical to TypeScript 6.0. That discipline matters because a from-scratch rewrite of a type checker would inevitably diverge in subtle judgments about which programs pass and which fail, and those differences would surface as spurious errors in millions of existing codebases. By porting the algorithm faithfully, Microsoft aimed to make the switch a performance upgrade that leaves a project's set of type errors unchanged. Teams can adopt the speed while keeping their type coverage steady.
The editor experience received the same treatment through a new language server built on the Language Server Protocol. Microsoft reports a 20x reduction in failing language-service commands compared with version 6.0, alongside dramatic latency improvements. Opening a file with errors in the VS Code codebase dropped from 17.5 seconds to under 1.3 seconds, roughly 13x faster. The watch mode was rebuilt on a ported Parcel file watcher, and type-checking parallelism is controllable through a new checkers flag defaulting to four workers, with a builders flag governing project-reference builds and a single-threaded mode available for debugging.
The breaking changes that matter
A major version arrives with removals, and TypeScript 7.0 clears out long-deprecated behavior. Output targeting ES5 is gone, as is support for the AMD and UMD module formats and the legacy classic module resolution strategy. These formats served an earlier era of the web, and their removal simplifies the compiler and pushes projects toward modern module standards. Two default changes will touch more teams. Strict mode is now enabled by default, so projects that relied on loose type-checking must opt out explicitly, and rootDir defaults to the current directory while the types option defaults to an empty array.
For most actively maintained projects, these changes are manageable, and many will already comply. The teams most affected are those carrying old configuration for compatibility with build systems that predate modern bundlers. Microsoft has documented the migration, and the fact that type-checking behavior is otherwise unchanged means the upgrade work concentrates in configuration rather than in fixing a flood of new type errors. We would still advise validating a build in a branch before adopting 7.0 across a monorepo, since the combination of strict-by-default and the removed targets can surface issues that were previously suppressed.
The API gap that stalls the ecosystem
The one caveat that will hold some teams back is the absence of a stable programmatic API. TypeScript 7.0 does not ship the compiler API that tools depend on to inspect and manipulate TypeScript programs, and that API is scheduled for 7.1. The consequence is immediate and specific. typescript-eslint's type-aware lint rules are built directly against the compiler API, so they cannot run on 7.0 yet. Bundlers and framework toolchains that reach into the compiler, including webpack integrations and the tooling behind Vue, MDX, and Angular, are in the same position and must continue using TypeScript 6.0 for those code paths.
This creates a transition period where a project can use TypeScript 7.0 for fast command-line type-checking while keeping TypeScript 6.0 installed for the tools that need the API. That dual-install arrangement is workable, and it adds friction that will keep some teams on 6.0 until 7.1 closes the gap. We read the sequencing as a deliberate tradeoff. Microsoft chose to ship the performance win to the broad base of users who type-check and edit code, then to follow with the API that a smaller set of tool authors requires. The ecosystem will converge once 7.1 lands.
What the Go rewrite signals
The choice of Go is itself a statement worth reading. Microsoft owns C#, and the team evaluated it, yet Go's combination of straightforward concurrency, fast compilation, and a garbage-collected model close to the original JavaScript made it the pragmatic vehicle for a faithful port. The decision underscores a broader movement across developer tooling toward native, systems-level languages for the hot paths that developers wait on. We have watched the same pattern play out in JavaScript bundlers and linters, where native cores replaced interpreted ones to reclaim time that scales with codebase size.
The strategic effect is that TypeScript's headroom now grows with hardware. Shared-memory parallelism means the compiler can put more cores to work as machines add them, which the single-threaded JavaScript implementation could never do. For large organizations, this changes the economics of a growing monorepo. Type-checking time that once climbed steadily with code volume now has substantial slack, and the editor stays responsive at scales that previously degraded the experience. The performance ceiling has moved far enough that most teams will stop treating type-check time as a constraint on how they structure their code.
The bottom line for teams
TypeScript 7.0 is the rare major release that delivers a large, measurable win with minimal behavioral change, and that combination makes the upgrade unusually attractive. The speed gains are real and drawn from production codebases, the type-checking semantics are preserved, and the breaking changes are concentrated in configuration that most modern projects have already adopted. For engineering leaders, the payoff shows up as faster continuous integration, quicker local feedback, and a more responsive editor for every developer who touches TypeScript. Those improvements compound across a large team every working day.
The one gating question is the programmatic API. Teams that depend on typescript-eslint's type-aware rules or on framework tooling that reads the compiler should plan a phased adoption, running 7.0 for type-checking while holding 6.0 for those integrations until 7.1 arrives. Everyone else can move now and capture the speed immediately. We recommend piloting 7.0 in a representative repository, confirming the configuration migration, and measuring the build and editor improvements against your own baseline. The numbers Microsoft published are strong, and the ones that matter for your decision are the ones you observe on your own code.
