TypeScript 2.6.2 keeps constant enum output consistent in watch mode

An incremental build must preserve the meaning of a clean build even when it does less work. TypeScript 2.6.2 includes a fix for a constant enum whose value refers to another constant enum. In the reported watch-mode case, recompiling a changed consumer emitted a reference to an enum object instead of the constant number. The output could then fail because that object did not exist at runtime.

The npm registry records the release on November 27. The release note lists bug fixes against 2.6.1 and support for JSX fragments. It is therefore more than an undifferentiated maintenance label. Its fixes concern both emitted program behavior and the language service's ability to report problems.

I value shorter editing cycles, but the compiler's first obligation is to preserve the program it emits. Watch mode should change how much work is repeated after an edit, not which runtime objects the resulting JavaScript requires. The enum correction addresses exactly that kind of discrepancy.

A constant value crosses three files

Issue 19898 provides a three-file reproduction. Its first file exports a constant enum with a member equal to 1. Another file exports a constant enum whose member refers to the first. The consumer imports the second enum and initializes a value from its member.

The report expects the consumer's emitted value always to be 1. In watch mode, after the third file changes, its JavaScript instead contains an access equivalent to E2.V. The issue identifies an unknown runtime reference as the resulting failure. The dependency between enum declarations matters even though the edit occurs in the consumer.

This is a useful boundary case for incremental emission. The compiler has already learned information from another file and must retain or reconstruct enough of it when processing the changed file. The observable requirement is consistency with the constant value. A faster build that emits a new runtime dependency has changed program behavior rather than merely omitting unnecessary work.

The report initially uses a development build, and its author confirms a fix in a subsequent development build on November 11. The release's fixed-issue tracking includes it in 2.6.2. That evidence supports the correction without requiring a claim that every possible constant-enum or incremental-build issue shares this cause.

Missing diagnostics can hide a service failure

Issue 19588 describes a different kind of inconsistency. A JavaScript file opts into checking with // @ts-check, assigns a number to a variable, and later assigns a string. The expected type error appears with the earlier comparison version in the report, but not in the reported 2.6 service arrangement.

The reproduction also involves an untitled JavaScript editor buffer. The issue's later clarification makes that step explicit. Its logs show a syntax-diagnostic response but no expected semantic-diagnostic response. They also expose an internal failure looking up script information for the untitled file in an inferred project.

That makes silence an unreliable signal in this case. The absence of an error did not establish that the checker had decided the assignment was valid. The semantic check failed to deliver its expected result. An editor depends on the service's project bookkeeping as well as its type rules before it can display a useful diagnostic.

I regard this distinction as important when evaluating gradual JavaScript checking. A file's opt-in comment has a clear purpose, and a project-state bug should not silently defeat it. Restoring the diagnostic path preserves the feedback the user explicitly requested, even though the JavaScript remains executable outside the checker.

Fragment syntax enters the compiler

The release note also links the JSX fragment implementation. That work adds the <>...</> form. Its description distinguishes preserving the syntax for another tool from transforming it through React-style emission. Supporting the source construct requires the parser and emitter to recognize an opening and closing fragment without an ordinary tag name.

The implementation discussion also considers custom JSX factories and fragment representation. That is a separate question from simply accepting the syntax. A framework-specific output operation needs a compatible runtime representation, while preserve mode can pass the syntax to another transform. The release's syntax support should not be interpreted as proof that every JSX framework or downstream tool already accepts the same arrangement.

The maintenance fixes and syntax addition affect different stages of the programming workflow. The enum correction keeps emitted behavior consistent across rebuilds, and the JavaScript service correction restores requested diagnostics. Fragment support extends the source the compiler can process, with output mode still determining which tool handles the construct next. Those are concrete properties to distinguish when adopting 2.6.2 instead of treating every change as another type-checking rule.