TypeScript 7 progress separates checker readiness from tooling migration

A compiler replacement can be ready to check an application's types while remaining unsuitable for a tool that embeds the old compiler API. Those are different dependencies on the same package. TypeScript's December native-port update makes that distinction central to the migration.

The December 2 progress report says the native checker is nearly complete and now supports incremental compilation, project references, and --build. Major editor operations previously absent from the preview are also available. The API for integrating other tools remains unfinished, and the JavaScript emit pipeline still has gaps.

The team also changes the development plan for the existing implementation. TypeScript 6.0 will be its last planned feature release. Limited patch servicing will follow, while development effort concentrates on bringing TypeScript 7 to parity and stability.

I remain ambivalent about TypeScript, but the ecosystem is a substantial reason to use it. That makes compatibility with the tools around the checker as important as checking speed. A migration account needs to identify which dependency a project has on the implementation before deciding whether the replacement is ready.

The preview now builds a project graph

The May preview announcement explicitly lacked --build and project-reference language-service support. It was useful for many individual checks, but that left an important gap for applications organized into several related projects.

December's update says those features are ported. The native compiler can coordinate multiple projects and use incremental state instead of repeating all work after a small change. This broadens the kinds of existing build structure it can support.

The distinction is more than command-line compatibility. A project graph has dependencies whose outputs and checking results influence later work. Supporting that graph is a separate responsibility from accepting one configuration file and checking its sources.

Shared-memory parallelism also extends across projects in the new implementation. The update describes building multiple projects in parallel as well as parallel work within a single project. That gives the compiler more opportunities to use available resources.

This does not establish that every build should use every core or that every graph has equally parallel work. Dependencies constrain which projects can proceed together. The architectural improvement is the ability to coordinate that work without requiring the application to flatten its project structure.

Checker evidence has a defined granularity

The report provides a useful measure of compatibility. The team has around 20,000 compiler test cases, with about 6,000 producing at least one error in TypeScript 6.0. In all but 74 of those error-producing cases, TypeScript 7 also produces at least one error.

Those counts support the team's claim that checking coverage is close to complete. They do not assert identical diagnostics, locations, or inferred types in every case. Producing an error in the same test is one compatibility observation at a particular granularity.

The remaining cases are described as known incomplete work or intentional differences. Examples include regular-expression syntax checking, isolated-declaration diagnostics, and changes associated with defaults or deprecations.

That distinction helps interpret feedback from an application. A new diagnostic can arise from a deliberate configuration change, while a missing diagnostic can reflect unfinished checking. Treating both as a single undifferentiated parity problem makes the migration harder to discuss.

The team says developers can use the preview for checking now. That is an authorial assessment backed by its test account, not a claim that the native compiler is already a final stable release. The package and editor extension remain native previews.

Editor readiness has advanced independently

The December language service includes auto-imports, find-all-references, rename, and signature help, alongside navigation and diagnostics. Those were substantial missing pieces in the May announcement.

That progress matters because checking an application and editing it are different workflows. A developer may tolerate a separate command-line checker while continuing to depend on the editor's rename or import support. The expanded operation set makes native-editor adoption practical for more of those workflows.

The implementation also uses a revised language-service architecture and Language Server Protocol. The March announcement already identified LSP as part of the native direction. December reports further restructuring for reliability and shared-memory parallelism.

The service layer has undergone more redesign than the core checker. An old editor bug may therefore no longer describe the same implementation path. The team plans to close older language-service issues and asks users to reproduce problems in the native nightly extension before filing them again.

That is a change to how evidence should be reported. The relevant reproduction needs to identify the new service and the operation it implements. A report about behavior absent from the preview cannot yet demonstrate a defect in that behavior.

Planned defaults require configuration migration

The update lists changes that TypeScript 6.0 will deprecate and TypeScript 7 will remove or replace. Among them are older Node module resolution, baseUrl, and the ES5 target. Strict checking will become the default.

These are announced migration policies. They should not be described as changes already applied to every stable TypeScript 5.9 project. The preview lets users encounter the new policy before the final transition.

The target policy also has two stages. The intended lowest supported target is ES2015, but the current native emit implementation realistically reaches only ES2021 for downlevel compilation. Planned support and current implementation coverage are different facts.

The report describes an experimental configuration-updating tool that handles baseUrl and rootDir. Its scope is limited to those settings at this point. It is not an automatic migration of every compiler option or framework integration.

For maintainers, explicit settings can distinguish reliance on a default from a deliberate compatibility commitment. A changed default has a different migration meaning when the project already states its intended behavior in configuration.

Emit and watch remain separate constraints

The JavaScript emit pipeline is not complete, including decorator compilation. A project using another tool to produce JavaScript may therefore adopt native checking sooner than one relying on TypeScript to generate code for an older runtime.

That is a useful example of independent toolchain responsibilities. The checker validates static relationships. An emitter transforms source into the runtime representation the deployment needs. A fast checker cannot compensate for a transformation that the emitter does not yet implement.

Watch mode also has efficiency limitations in some scenarios. The report suggests alternatives that rerun the compiler with incremental state. Those are workarounds for a particular execution mode, not evidence that the ordinary one-pass checker has the same performance problem.

My preference is to treat those responsibilities explicitly when evaluating a compiler transition. The quality of a TypeScript application depends on its framework and runtime conventions. Preserving the right emit semantics matters more than making every tool in the workflow share one implementation immediately.

The old API is not the new integration contract

The native implementation will not support the existing JavaScript compiler API. The report states that the Corsa API remains work in progress and has no stable tooling integration. Linters, formatters, and editor extensions depending on the old API therefore cannot assume a drop-in replacement.

The earlier API discussion explains the underlying boundary. Moving computation into a separate runtime requires message passing and deliberate operations instead of unrestricted access to an in-process object graph.

That design creates a migration question even if TypeScript answers remain highly compatible. A tool may need to traverse or modify compiler objects in ways the new API does not yet expose. Command-line compatibility does not supply that missing operation.

Installing both packages is an explicit supported workaround in the report. The native compiler can perform checking while API-dependent tools retain the existing implementation. The inverse arrangement can also make sense when the editor benefits from native service performance while command-line tooling still requires the old API.

This is a practical consequence of separating responsibilities. A repository can adopt native checking without claiming that its entire tool ecosystem has migrated. Each integration can move when the capability it needs exists.

TypeScript 6 becomes a transition release

The new roadmap says there is no planned TypeScript 6.1. Subsequent 6.0 patches will be reserved for security issues, serious regressions, and high-severity compatibility fixes involving the transition.

The project also raises the bar for changes to the JavaScript line immediately. That is an allocation decision, reducing parallel feature work so the team can complete the native implementation. Contributors need to know this because a useful change may still fall outside the remaining scope of that line.

The concrete migration path now has several independently assessable parts. Native checking and project builds are broadly available in preview, editor coverage has expanded, and configuration changes have been identified. Emit coverage and API integration remain reasons to retain the existing implementation for particular operations. TypeScript 6.0 provides the final planned JavaScript-based transition point while those dependencies are addressed.