TypeScript 5.6: let the compiler reject suspicious conditions

A condition can be valid JavaScript and still fail to ask the question its author intended. TypeScript 5.6 made a useful decision: reject some expressions whose syntax already reveals that the condition cannot behave as expected. For a team maintaining an application, that is a good reason to trial a compiler upgrade. It is also a narrow promise. The compiler cannot decide whether the business rule behind an otherwise sensible condition is correct.

Looking back from November 2026, the July milestone needs its proper label. Microsoft announced TypeScript 5.6 Beta on 26 July 2024. The stable release followed on 9 September. July offered an opportunity to investigate new diagnostics, rather than a stable release that every production team should immediately adopt.

A mistake the syntax can expose

Microsoft's beta examples include a regular-expression object used as an if condition without a call to .test(...), an arrow function typed where a comparison was intended, and a comparison combined with ?? under mistaken assumptions about precedence. The beta announcement identifies these as disallowed nullish and truthy checks. These are ordinary editing mistakes with potentially consequential behaviour, not exotic failures of the type system.

The useful distinction is between a condition's appearance and its meaning to JavaScript. A developer may see a pattern and assume the program is testing some text. The runtime sees an object. A reviewer may read a familiar comparison shape and miss that the operator creates a function. Syntax can provide enough evidence for a diagnostic before any real data arrives.

That makes the compiler a good place for the check. Once adopted in the project's actual checking path, the diagnostic does not depend on the next reviewer noticing the typo. This is a recommendation about where to put a repeatable check, not a measured claim about how many bugs an application will lose.

Three different questions about correctness

A syntactic diagnostic asks whether the expression has a suspiciously fixed outcome. Type narrowing asks what can be known about a value along a particular path. Runtime validation asks whether an incoming value satisfies the application's requirements. These questions can overlap in a program, but success at one does not answer the others.

Consider an illustrative order system. A condition may compare a valid numeric total against a valid numeric limit and still use the wrong limit for that customer. Its syntax can be reasonable, its types can agree, and the business decision can remain wrong. A test expressing the agreed customer rule has a job that a compiler upgrade cannot take over.

Likewise, a boundary receiving external data needs a deliberate response to missing or malformed values. Declaring what the application expects does not establish what a remote sender actually supplied. The July diagnostics are a reason to remove an avoidable class of mistakes, not a reason to trust incoming data more broadly.

The distinction matters for budgeting. An upgrade can be useful without replacing a testing project. A team that sells it as a substitute for validation will leave the wrong work undone. A team that treats every new diagnostic as irrelevant because tests already exist will miss a cheap place to catch mistakes before those tests run.

Trial the compiler against the project you maintain

A sensible historical response to the beta would have been a separate, reversible assessment. Pin the compiler under evaluation, run the project's normal checks, and inspect the new diagnostics. Keep compiler adoption separate from unrelated refactoring so that any change in reported errors has an understandable cause.

For each suspicious condition, establish the intended rule before editing it. Automatically adding a comparison or suppressing the error may make the diagnostic disappear while preserving a misunderstanding. If the intended behaviour cannot be established from nearby code or a specification, ask the person responsible for that rule. The goal is a correct decision in the application.

A beta also brings uncertainty beyond its headline feature. September's stable announcement explicitly records changes since the beta, including reverted language-service behaviour and renamed iterator types. That later evidence explains why a July trial and a September adoption decision are separate activities. It should not be projected backward as July availability.

The strongest objection: another upgrade can wait

A team facing a fixed release date may already catch related mistakes through linting and review. It may judge beta compiler work a poor use of scarce time. That is a strong objection, particularly when the toolchain or editor integration is sensitive to version changes.

Microsoft's stable notes acknowledge a related ESLint rule and say its coverage does not perfectly overlap with the compiler checks. Existing linting therefore matters, but it does not establish equivalence. Assess the actual checks in the repository before claiming the new compiler adds nothing, or before claiming it replaces linting entirely.

The recommendation has a clear limit: trial useful diagnostics when the investigation is affordable, then schedule adoption against compatibility and release needs. It does not require shipping with a beta. An application with no TypeScript checking path may need a broader tooling decision before this particular feature matters.

When arranging software maintenance, ask for an account of the errors found, the intended behaviours confirmed and the compatibility work required. A larger version number is a weak outcome. A compiler that consistently rejects a known mistake, while the application still checks its real business rules, is a useful one.