TypeScript 7.0 beta exposes the cost of parallel checking
The Go compiler beta adds explicit checker and project-builder controls. Its worker model explains why more parallelism can improve latency while increasing memory use.
The TypeScript 7.0 beta arrives on April 21 with a native Go implementation and explicit controls over parallel work. The announcement reports that it is often about ten times faster than TypeScript 6.0. More revealing than that headline is the explanation of how the compiler divides checking and the memory costs that follow.
This is a port of the existing implementation, with structurally equivalent checking logic, rather than a new language design. The TypeScript 6.0 release prepared projects for its defaults and removals. The beta now makes the implementation available through @typescript/native-preview@beta, using the tsgo executable alongside the current compiler.
Faster tooling matters to my appreciation of TypeScript's web ecosystem. Framework-heavy applications depend on a checker that can understand a substantial program without making the editing experience cumbersome. The beta's resource controls are important because development machines and CI runners do not have identical budgets.
Checking cannot divide like independent file parsing
The announcement distinguishes stages with relatively independent work from stages with shared dependencies. Parsing and emitting can divide naturally across files. Type checking repeatedly needs information from dependencies and the global scope, so completely independent checking could duplicate substantial work and memory.
TypeScript 7 creates a fixed number of checker workers, each with its own view of the program. Some common work is duplicated, but the same input files divide consistently for a given worker configuration. That preserves a defined schedule where arbitrary division could expose order-dependent behavior.
The default checker count is four. --checkers changes it, with an explicit tradeoff between possible speed improvements and memory consumption. A larger count is not a free use of otherwise idle cores. Each additional checker can require more of the shared program information in its own working state.
The announcement also notes rare cases where changing the checker count can reveal order-dependent results. Fixing the count across a project provides a more consistent comparison. The beta does not claim that every possible worker configuration is behaviorally indistinguishable in every inference corner case.
Project builders multiply the worker budget
Project-reference builds add another level of concurrency through --builders. Several projects can build at once where the dependency graph permits it. That is useful for a repository with multiple independent projects, but it also multiplies the number of active checker workers.
The announcement's example is four builders with four checkers, allowing as many as sixteen checkers. An outer build orchestrator can introduce another source of parallel work. A setting that seems modest inside one compiler process can therefore create excessive concurrency across the whole build.
The beta also provides --singleThreaded. It constrains parsing and emitting as well as setting checking to one worker. This differs from merely selecting one checker while other stages remain parallel. It gives debugging and externally orchestrated builds a way to establish a genuinely single-threaded compiler run.
tsgo --project tsconfig.json --singleThreaded
That command is a configuration example, not a performance result. It selects a defined resource mode. Comparing it with another mode can help distinguish native execution benefits from gains due to several workers operating at once.
Compiler adoption and API adoption differ
The beta's package and executable names allow comparison with TypeScript 6 without replacing the existing tsc command. The announcement also introduces @typescript/typescript6, which exposes tsc6 and re-exports the JavaScript compiler API. That compatibility path matters to tools that consume the implementation programmatically.
A stable native programmatic API is not part of this beta. The announcement places it at TypeScript 7.1 or later. A project can therefore be ready to use the native command-line checker while a lint tool or compiler-API integration still needs the JavaScript implementation.
This is a useful separation in the migration design. Invoking a compiler executable has a different integration contract from importing compiler objects into another JavaScript process. Performance parity at the command line cannot make those imported objects appear in the native package.
The editor takes another route through the TypeScript Native Preview extension and the Language Server Protocol. That lets an editor communicate with the native service without embedding the old JavaScript language-service implementation. The beta announcement describes this as the same foundation used by the command-line experience.
My preference is for that kind of explicit integration boundary. TypeScript's value depends on the surrounding tools as much as its syntax, and different tools need different migration paths. The beta provides a native checker, a separately selectable editor service, and a compatibility package for tools that still require the older API.
For a project already compatible with TypeScript 6, the available choices are concrete. The beta supports a parallel native build with configurable worker counts, and it supports a single-threaded run when that better fits the machine or build orchestration. The stable API remains separate work, so compiler speed can improve before every ecosystem integration moves to the new implementation.