TypeScript 5.3.3 repairs optional-chain narrowing

A condition can prove that an optional object exists inside one branch without proving that it exists afterward. TypeScript 5.3.3 fixes a regression where comparing an optional-chained property with false allowed that branch-local fact to escape into later code. The result was more serious than an inconvenient diagnostic. The checker could accept a property access that might fail at runtime.

The npm registry records version 5.3.3 at December 6, 2023. Its GitHub release links the maintenance milestone, which includes the optional-chain narrowing report and its fix. The release also repairs compatibility in the declarations used by compiler and lint-tool consumers.

I rely on TypeScript's ability to make unsafe paths visible more than I enjoy its type-system complexity. A narrowing regression matters because successful checking is part of the feedback loop. Silently removing undefined from a reachable path weakens exactly the property that makes the checker useful.

The condition proves a fact only on its own path

The reported example declares an object that may be undefined, then checks whether its optional-chained boolean property equals false. If the condition succeeds, the object must exist. An absent object would make the optional-chain result undefined, which does not equal false.

interface State {
    ready: boolean;
}

declare const state: State | undefined;

if (state?.ready === false) {
    console.log(state.ready);
}

// This still needs an undefined check.
console.log(state.ready);

The final access is unsafe under strict null checking. Reaching it does not imply that the if body ran. Execution can bypass the body because state is undefined, so the value afterward must still include that possibility.

The issue reports that the earlier 5.3 behavior incorrectly narrowed the object after the statement. A TypeScript expected-error directive on the later access became unused because the diagnostic disappeared. The fix restores the requirement to check the value where that possibility remains reachable.

This is a control-flow distinction, not a change to optional chaining at runtime. The emitted JavaScript still permits the absent case. The maintenance work corrects the analysis so its accepted operations match the paths the program can actually take.

The wider 5.3 release added recognition of explicit boolean comparisons during narrowing. This regression shows why adding a recognized condition also requires preserving the boundaries of its evidence. A true branch and the point where branches rejoin have different possible incoming states. Restoring that distinction keeps the useful new conditional form while preventing its conclusion from applying outside the path that established it.

The original report also shows the problem in JSX, where one expression checks the optional property and a separate expression later dereferences the object. Those expressions are distinct uses. A check producing one rendered value does not automatically establish a guard around another expression beside it.

A compiler declaration can have its own strictness bug

Another maintenance issue affected consumers importing types from the TypeScript package with exactOptionalPropertyTypes enabled. The report demonstrates a minimal import of CompilerOptions producing an error inside typescript.d.ts.

The mismatch involved jsDocParsingMode on Project and LanguageServiceHost. One declaration permitted undefined as a present value, while the other optional property did not explicitly include it. Under exact optional checking, absence and a present property containing undefined are different states.

The repair matters to tools embedding the compiler even when their application source does not use the new JSDoc API directly. Importing the package's declarations brings their internal compatibility relationships into the consumer's check. A declaration inconsistency can therefore block a project far from the feature that introduced it.

This is another reason I distinguish a compiler version's language features from the experience of using its API. A build tool or linter consumes TypeScript as a library. Its compatibility includes the declarations through which it accesses that library, under the strictness settings it supports.

Deprecated AST names still carry compatibility obligations

The AssertEntry and AssertClause report describes another tool-facing regression. During the import-attributes update, deprecated assertion-node names remained available but changed from interfaces to type aliases. That preserved their names while changing how other declarations could interact with them.

The typescript-eslint integration used interface declaration merging to support TypeScript versions where particular AST names did not yet exist. Empty interface declarations supplied compatibility names on older versions and merged on newer versions. A type alias cannot participate in the same merging arrangement.

The maintenance fix restores those deprecated names as interfaces extending the corresponding attribute types. This preserves the newer representation while allowing the established declaration relationship to continue. Deprecated does not mean unused, especially for tooling supporting several compiler versions.

The report also explains why local testing missed the problem. Suppressed diagnostics and skipLibCheck hid errors inside the contributing repository, while emitted declarations exposed them to a consumer. That account identifies a concrete difference between testing a package internally and checking the artifact another project receives. TypeScript 5.3.3 repairs that consumer-facing contract alongside the application-level narrowing fix.