TypeScript 2.7.2 repairs diagnostics during incremental compilation

A compiler that caches type information must preserve the work associated with discovering that information. If an earlier operation resolves an expression but skips recording its diagnostics, a later operation may reuse the cached result without repeating the checks. TypeScript 2.7.2 repairs such an interaction between emission and diagnostic collection.

The npm registry records publication of 2.7.2 on February 15. Its release entry identifies it as a collection of fixes reported against 2.7.1. The tag-to-tag patch supplies the implementation detail, including a correction associated with issue 21518.

I find TypeScript useful because its tooling supports careful work in the browser ecosystem, despite reservations about the language's complexity. Diagnostics are central to that usefulness. A maintenance release that makes them consistent across compiler operations improves the meaning of the feedback developers already rely upon.

Cached resolution was skipping associated checks

The patch explanation says diagnostic reporting and expression-resolution caching are intertwined. Requesting declaration output without collecting diagnostics could cache resolution for function return expressions. Errors would not be reported, and symbols would not be marked as referenced. A later request for diagnostics could encounter the cached expression and avoid the work that should have supplied those results.

This is a compiler-state problem. The source program has not necessarily changed between the two operations. What changes is which compiler operation runs first and which information it leaves behind. Reusing a type result is correct only if the rest of the compiler can rely on the associated state it expects.

The correction removes the option to skip diagnostic collection from the emission resolver's internal interface. getEmitResolver() now calls getDiagnostics() before returning its resolver. The corresponding call from the program's emission path no longer passes the declaration-only flag as a reason to avoid diagnostics.

That implementation supplies a concrete explanation for the repair. It does not merely clear a cache and hope the behaviour disappears. It makes the prerequisite work part of obtaining the resolver, so the emitter and later diagnostic queries do not disagree about whether the checks have happened.

The affected information includes whether symbols count as referenced. That explains why an interaction around declaration output can become visible through an unused-code diagnostic. Diagnostics often rely on facts collected while the checker resolves expressions, even if the diagnostic itself appears to concern a different part of the source.

A file changing into a module exercises the state transition

The patch adds a watch-mode test that begins with a file containing ordinary functions, then adds an export so the file becomes a module. The compiler runs with noUnusedLocals. A nested returned function calls another function in the same file, so the reference must remain recognized after the edit.

The test checks the diagnostics before and after the file change. Its purpose is to prevent an incorrect unused-function error during the transition. This test retains the watched program across the edit, so it covers a transition that a fresh compilation would not reproduce. That is a stronger description than saying the release improves watch mode, because it identifies the edit and the contract the test protects.

This matters to a developer who keeps the compiler running while editing. An unchanged-looking reference can acquire a false diagnostic if the compiler reuses state incorrectly after an edit changes the file's role. Restarting the compiler may obscure that transition, while a test retaining the watched program can exercise it directly.

The test establishes the intended behaviour for this case. It does not prove that every incremental-compilation path is free of stale state. The value of the release is the specific repair and regression example, with a source-level explanation of why diagnostic work must accompany resolution.

Watch output can retain the information being requested

Another patch changes console clearing when --diagnostics or --extendedDiagnostics is enabled. TypeScript 2.7 introduced clearing the watch console during recompilation. Version 2.7.2 excludes those diagnostic modes from clearing, so their output remains available across watch activity.

The implementation passes compiler options into the watch-status reporting callback and checks the two flags before clearing the screen. Tests cover ordinary watch mode and each diagnostic mode separately. The behavioural distinction therefore follows the user's requested output mode rather than relying on a terminal-specific workaround.

These corrections affect different parts of the same workflow. Diagnostic collection decides which findings exist, while status reporting decides whether output remains visible. Neither requires a new type-system feature to matter. My preference is for a compiler whose persistent editing session reports the same source facts consistently, with diagnostic output retained when the user has explicitly requested it. TypeScript 2.7.2 addresses both through bounded changes to its existing implementation.