A preview TypeScript checker should earn the right to block a release
TypeScript’s May native preview made parallel diagnostic evaluation practical. Compare coverage and disagreements before granting a checker release authority.
By 
Paul. Languages and frameworks
A faster checker should earn release authority through the evidence it produces on your project. Run a preview beside the established checker, understand disagreements and only then decide whether it can block or permit a release. The aim is dependable feedback sooner. Replacing a familiar command before understanding its coverage can make a green pipeline less informative.
Looking back from November 2026, the 22 May 2025 TypeScript Native Previews announcement made this a practical adoption question. Microsoft offered a separate preview package with the tsgo executable. That milestone followed the 11 March native-port announcement; it was not the first stable release of TypeScript 7. A roadmap and an installable preview provide different grounds for a decision.
Decide what the parallel run must prove
This article concerns the authority of command-line diagnostics. It is a narrower question than whether compiler API consumers, editor plugins or documentation generators can migrate to a new implementation. Those integrations still need their own assessment. Here, the immediate boundary is the result that continuous integration treats as evidence for accepting the application’s source.
Consider a proposed evaluation of a modern web package. Keep the established checker responsible for the release while the preview reports alongside it. Pin both tool versions and retain the revision, dependencies and configuration used for each run. This is a suggested experiment, not a compatibility test performed for this article or an AL+ benchmark.
Matching exit statuses are insufficient. Two commands can both succeed because neither encountered the code path that matters. Two can both fail while identifying different problems. Compare the included files, compiler options and meaningful diagnostics, then explain discrepancies. Otherwise apparent agreement can hide missing coverage or a different interpretation of the same project boundary.
The comparison should also include representative failures that the product relies on type checking to catch. Use existing relevant cases or deliberately prepared fixtures in an authorized evaluation. State the property each case exercises. A preview should not receive credit for catching a planted error in an unrelated isolated file while the actual release configuration excludes the affected package.
Classify differences before changing the gate
A diagnostic present only in the established checker could indicate a preview gap, but that is a hypothesis to investigate. A diagnostic present only in the preview might reveal a genuine issue or a changed rule. Differences in ordering or presentation might be harmless. Treating every textual difference as a regression creates noise; ignoring every difference creates unjustified confidence.
For each meaningful disagreement, retain a reproducible case and name the intended outcome. If the difference is accepted, explain why it does not weaken the required contract. If it is unresolved, keep it visible rather than adding a broad suppression. A release decision needs an account of what the check means, not merely an attractive count of passing runs.
The May announcement explicitly described incomplete functionality and differences. That warning belongs to the historical preview discussed here. It must not be recycled as a claim that the same features remain absent in November 2026. Conversely, a current feature list cannot prove that a May preview already supported a workflow at the time.
This retrospective therefore does not announce a present-day switch recommendation for an unspecified compiler version. Anyone evaluating now should identify the exact published artifact and its applicable release documentation. The historical recommendation remains useful because its acceptance criterion survives feature changes: unexplained diagnostic disagreement should not silently change release authority.
Keep speed evidence attached to its workload
Microsoft published performance results in the native-port announcements. Those are vendor measurements on the stated examples, not results for the proposed package. They justify investigating a bottleneck; they do not establish a local speedup, memory saving or financial return. No compiler was installed or timed for this article.
A future evaluation should distinguish checker execution time from the delay a developer experiences. Dependency installation, job scheduling and other pipeline work can dominate the latter. Measure the interval that the adoption decision is intended to improve. Record whether caches and resources are comparable before using timing to justify a change.
Diagnostic coverage comes first because speed can otherwise reward omitted work. A shorter run that examines fewer relevant files is not an equivalent substitute. Once the required coverage and accepted differences are understood, performance becomes useful evidence for deciding whether the remaining migration effort is worthwhile.
The business benefit depends on the work being delayed. Faster reliable feedback may help a developer continue a change sooner. It may barely affect a release waiting on unrelated integration checks. Avoid translating a vendor multiplier directly into a delivery estimate, especially when nobody has measured how much of the team’s waiting belongs to type checking.
Non-blocking evaluation should have an end condition
Parallel runs also have a cost. They consume compute and attention, and unexplained warnings can become background noise. Assign someone to investigate meaningful disagreements and define what evidence would end the evaluation. That might be promotion, a documented narrower role or removal until a missing capability arrives. No fixed number of days establishes correctness by itself.
The strongest counterargument is that an isolated, modern project with limited compiler requirements may accept preview limitations immediately. A long parallel phase could delay a useful improvement without finding much. That can be reasonable when the owner understands the requirements and accepts the risk. The evaluation should scale to the decision, rather than become a ritual.
A large mixed repository has a different exposure. One package’s agreement does not establish coverage for every configuration. Promotion can be scoped to the package actually evaluated, while other packages retain their existing gate. Keep a documented route back if a later disagreement invalidates the assumptions behind the decision.
For custom software development, hand over the checker’s authority with its evidence: versions, configuration, explained differences and reversal conditions. The May preview created an opportunity to gather that evidence. Granting release authority should follow the project’s results, rather than precede them on the strength of a performance headline.