TypeScript 7.0 RC replaces expensive polling in watch mode
The native compiler's release candidate brings a Go port of Parcel's watcher. It also moves the compiler to the normal package name while preserving a separate path for older API integrations.
Porting TypeScript's checker to Go left a less visible problem in continuous development. The team needed efficient file watching across operating systems, and the available polling solution was too expensive for general use. The TypeScript 7.0 release candidate announcement, published on June 18, describes how a port of Parcel's watcher supplied that missing implementation.
The RC also brings the native compiler to the ordinary typescript package and tsc command through the release-candidate distribution tag. That changes installation from the separately named preview used by the April beta. The code remains a candidate release as of today, with stable publication planned within the following month.
TypeScript's ecosystem makes sophisticated web interfaces practical, which is the part of the language I value most. Continuous feedback is part of that experience. A fast checker whose watcher consumes excessive resources between edits would leave an important part of the development workflow unfinished.
Polling worked but imposed recurring cost
The RC announcement says Go's standard library does not provide a file-watching API. Third-party options presented problems involving stability, performance, platform coverage, or build integration. Polling periodically for changes worked across systems, but it was computationally expensive for large projects and their dependency directories.
That cost differs from the work required to check a changed program. Polling spends resources to discover whether there is new work at all. Improving checker throughput does not automatically improve that discovery process. A continuously running compiler needs both operations to fit the machine on which it runs.
The team tried dynamic polling schedules, but the announcement says those were still too taxing for general use. That is a useful architectural detail because it explains why another round of polling adjustments was insufficient. The issue was the mechanism used to observe changes, not simply the frequency of one fixed timer.
Visual Studio Code already used Parcel's watcher, including indirectly for TypeScript. That provided evidence for an implementation with a relevant workload. Its C++ codebase, however, would have introduced a full C++ toolchain into the native compiler's build requirements.
Reusing a design without adding another toolchain
The team ported the watcher to Go with small assembly shims. According to the announcement, the work began as a direct translation and then moved toward idiomatic Go while retaining the ported tests. The resulting watcher is a self-contained package.
That choice preserves a useful boundary. The watcher implements how to observe filesystem changes. The compiler decides what it needs to watch and how a change affects the program. Keeping those concerns separate avoids embedding all platform-specific observation behavior into checking logic.
The release reports resource improvements across platforms and positive early feedback. It does not provide a universal CPU or memory figure for every project, so the concrete conclusion is the implementation change itself. Watch mode now has a different foundation from the pure-polling approach described in the development history.
This is the kind of reuse I find persuasive. The team selected an implementation already relevant to its editor workload, then accounted for the build dependency that direct adoption would introduce. The result serves the native compiler without requiring every contributor to add another language toolchain merely to build the watcher.
The package name changes before the API does
The release candidate can be installed as typescript@rc and invoked through tsc. The announcement's version example reports 7.0.1-rc, despite the release being called TypeScript 7.0 RC. Distinguishing the release label from the executable's reported version avoids prescribing a package version that the source does not show.
Tools importing the JavaScript compiler API still have a separate compatibility path. A stable native programmatic API remains planned for TypeScript 7.1 or later. @typescript/typescript6 supplies the older API and a tsc6 executable, allowing a project to keep those integrations while adopting the native command-line compiler.
An npm alias can retain the old API under the import name a dependent tool expects. Another alias can provide the native package and its executable. The RC announcement explains both roles because package resolution and command selection are separate integration decisions. Merely observing a faster tsc invocation does not establish which API a lint tool imported.
Compatibility also includes type-level strings
One RC change affects template-literal type inference. Splitting the first inferred component from a string now preserves a Unicode code point instead of splitting a surrogate pair. The announcement demonstrates the difference with an emoji followed by ordinary letters.
The new behavior follows the intuition of string iteration, but it breaks type utilities intentionally modeling UTF-16 code units. That is a specific compatibility change within a broadly compatible compiler port. It also shows why a native implementation's compatibility claim needs documented exceptions beyond command-line configuration.
For continuous development, the RC's immediate improvement is the watcher foundation and the completed editor features listed in the announcement. The ordinary package name now reaches the native executable, while older API consumers retain their compatibility route. That gives the release a usable integration story for both repeated local builds and tools that cannot yet move their programmatic dependency.