TypeScript 7 makes native checking standard while API integrations wait

TypeScript 7 ships on July 8 as the standard typescript package, with a native compiler written in Go. The announcement reports typical full-build improvements of eight to twelve times over TypeScript 6. There is also a consequential limit. Version 7.0 does not ship a programmatic compiler API, so some framework integrations must continue using the JavaScript implementation.

That combination explains who can benefit immediately. A build invoking tsc and an editor talking to the new language server have available native implementations. A tool embedding compiler objects inside its own analysis cannot assume the same migration path. The performance result and the integration contract are separate parts of this release.

My view of TypeScript is still mixed, but the web ecosystem it enables is valuable. Framework idioms matter to producing a coherent interface, and those frameworks rely on tooling beyond the compiler command. This release is most interesting when considered in terms of that complete working environment, including the components that cannot move yet.

A faithful port changes execution machinery

The team describes TypeScript 7 as a faithful port that preserves the structure and logic of the existing implementation where possible. Native execution and shared-memory multithreading supply a different performance foundation. The project is not asking users to learn an unrelated type system to obtain the speed improvement.

The direction dates to the March 2025 native-port announcement. That plan connected performance to large-project editor loading and complete checking. A compiler too slow to provide a full view during ordinary editing limits the practical value of its semantic information.

The final announcement gives concrete examples. Checking the VS Code codebase falls from 125.7 seconds with TypeScript 6 to 10.6 seconds with TypeScript 7 in the published comparison. Playwright falls from 12.8 seconds to 1.47 seconds. These are the team's reported measurements on its selected projects, not results from my own systems.

The distinction matters because the headline is a typical range, not a constant attached to every invocation. Project structure and hardware influence how much parallel work is available. A small check can have different dominant costs from a full build of a large repository. The release provides evidence of a substantial improvement without making those workloads identical.

Editor startup is another operation with its own measurement. The announcement reports that opening a file containing an error in the VS Code project moves from roughly 17.5 seconds until the first error to under 1.3 seconds on the same computer. That is useful because users encounter project loading before they encounter a full command-line build.

The language server supplies an external boundary

The native editor service uses the Language Server Protocol. An editor can communicate with the service rather than importing the old JavaScript language-service implementation. The release describes a dedicated TypeScript 7 extension for VS Code and workspace-based selection in Visual Studio.

This boundary gives the compiler an independent implementation process. Completion, navigation, and diagnostics can come from the native service while the editor retains its own implementation language. It also allows the service to use multiple threads for simultaneous requests, as described in the announcement.

The service is broader than a command-line checker. The release lists editor functionality added during development, including auto-imports, inlay hints, and JSX editing support. Features missing from the beta, such as semantic highlighting and more specific import commands, are now included. A fast build alone would not account for those editing operations.

The June release-candidate announcement also describes the new watcher foundation. The team ported Parcel's watcher to Go after finding pure polling too expensive for general use. That work matters to long-running feedback between edits, where detecting changes has its own resource cost.

Together, those details describe a usable native development service. They are more informative than assuming that replacing the compiler automatically replaces every surrounding component. The editor protocol and file watcher needed their own implementations.

Embedded framework languages have another dependency

The final release explicitly discusses Vue, MDX, Astro, and Svelte workflows. Tools such as Volar embed TypeScript into their compilers and language services. Without a stable programmatic API in TypeScript 7, those integrations still rely on TypeScript 6.

Angular has a related but distinct path in the announcement. Projects can use the native command-line compiler for fast project-wide error detection while retaining TypeScript 6 for editor support. The release does not present that as equivalent to moving specialized template checking to the native implementation.

This is an important limit for a language whose appeal includes frameworks. A component file may combine template syntax with code that needs TypeScript's semantic analysis. Its tool has to connect those representations through an integration more specialized than sending ordinary TypeScript files to tsc.

The missing API therefore constrains a real use case. It is not merely an inconvenience for optional compiler experiments. The release plans a new and different API for TypeScript 7.1, which remains future work as of today. Existing integrations cannot treat that planned interface as already available.

For me, framework support is part of assessing the release's practical reach. The native CLI can be a substantial improvement while a particular editor workflow remains on the older implementation. Stating that division precisely is more useful than assigning one migration status to an entire repository.

Compatibility packages preserve the older API

@typescript/typescript6 supplies the older compiler API and a tsc6 executable. The release documents npm aliases for tools whose peer dependency expects to import a package named typescript. Another alias can provide the native package and its tsc executable.

The resulting arrangement distinguishes imported APIs from executable commands. A lint integration can still resolve the JavaScript implementation it understands, while a build command invokes the native compiler. The package names express those roles explicitly instead of requiring whichever dependency happens to win executable resolution.

The announcement uses the following dependency arrangement for that transition. These versions are the ones shown in the release guidance.

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

This is not the same as installing only the compatibility package. The compatibility package supplies tsc6; the separate native dependency supplies version 7's tsc. The command selected by build scripts and the API selected by a dependent package both deserve a defined identity.

Parallelism has a resource budget

TypeScript 7 defaults to four checker workers. The experimental --checkers flag changes that number, while --builders controls parallel project-reference builds under build mode. More builders can multiply the number of simultaneous checkers, increasing the possible memory cost.

The beta announcement explains why workers have their own view of shared program information. Checking depends on global declarations and common dependencies, so arbitrary independent work would duplicate substantial computation. A fixed worker division gives the compiler a consistent scheme for the same inputs.

The final release preserves a warning about rare order-dependent results when the checker count changes. It also offers --singleThreaded for a compiler run whose parsing and emitting are constrained along with checking. Selecting one checker alone is a narrower control.

The published benchmarks show that more checkers can improve these particular large-project builds further. That does not make the maximum worker count an appropriate default for every machine. A build pipeline can already be running independent projects through another orchestrator, and its total concurrency includes those outer processes.

This is a practical part of the native design. Performance improvements arrive with controls that make the resource model visible. The compiler can exploit a larger machine while a constrained runner can avoid paying for unnecessary duplicated checker state.

Compatibility starts with the transition release

The release defines its main compatibility expectation against TypeScript 6 with stable type ordering enabled and deprecated settings removed. TypeScript 7 adopts the new defaults and turns the earlier deprecations into hard errors. A project that suppressed the TypeScript 6 deprecations has therefore postponed work that the native compiler still requires.

The separate TypeScript 6.0 announcement explains why stable ordering matters. Internal creation order cannot reliably determine displayed types when checking work runs in parallel. The transition flag lets the JavaScript implementation expose ordering differences before the executable changes.

For a compatible plain TypeScript workflow, the stable native command is now available through the ordinary package. For embedded framework tooling, the older API remains an active dependency until the replacement integration exists. Those are both current facts of TypeScript 7.0, and they let a project adopt the available performance gains without misrepresenting the parts that still depend on version 6.