Narrowing Lost Across Closures

## What narrowing actually is TypeScript's type checker runs a control-flow analysis over each function body. It walks the statements in order and, at every reference to a variable, computes the type that variable must have *at that point* given the checks and assignments it has passed through. `socket` is declared `WebSocket | null`; after `if (socket !== null)` the checker records that on the true branch the reference has type `WebSocket`. All of this is compile-time bookkeeping — nothing about it exists in the emitted JavaScript. ## Why a function boundary ends the analysis The analysis is *ordered*. Statements in a body execute one after another, so the checker can say "by the time we reach line 7, the check on line 5 has run and nothing has reassigned the variable". A nested function has no position in that order. It is a value; it can be stored, passed, invoked once, invoked a thousand times, or invoked next week. `queueMicrotask(() => socket.send(data))` schedules the body for later, and between the check and the invocation the module's own `connect()` — or a reconnect handler, or a teardown that sets `socket = null` — may have run. So the rule is: when a reference to an outer variable appears inside a nested function, the checker asks whether the binding could ever change. If it could, it abandons the outer flow facts and uses the **declared** type, here `WebSocket | null`. Calling `.send` on that is an error. The mechanics of how the closure captures the binding at runtime are ordinary JavaScript scope rules; what matters here is only what the checker is willing to assume about *when* the body runs. ```ts let socket: WebSocket | null = null; function connect(url: string) { socket = new WebSocket(url); } function send(data: string) { if (socket !== null) { socket.send(data); // ok: same flow, no assignment between queueMicrotask(() => socket.send(data)); // error: 'socket' is possibly 'null' } } ``` Note the asymmetry in the first line: the direct call is accepted even though `connect()` could in principle be re-entered by another task. That is a deliberate, documented unsoundness — the checker trusts straight-line flow — while the deferred body is where it refuses to guess. ## What counts as "cannot change" - A `const` binding can never be reassigned, so its narrowing is always available inside closures. - A parameter or a `let` that is never assigned anywhere is treated the same way: no assignment exists, so nothing can invalidate the fact. - A `let` that *is* assigned somewhere is the failing case, and it fails even when the assignment lives in an entirely different function — the checker does not attempt to prove the two can never interleave. Since TypeScript 5.4 the rule is more generous: if every assignment to the variable appears **before** the function expression is created, the narrowing at that point is preserved inside the body. That covers the common shape where you normalise a parameter and then use it in a callback: ```ts function render(url: string | URL, names: string[]) { if (typeof url === "string") url = new URL(url); // last assignment return names.map(n => url.href + n); // 5.4+: url is URL here } ``` The `socket` case is not covered, because `connect()` assigns after — and TypeScript makes no attempt at inter-procedural ordering. ## The fix Capture the narrowed value in a new `const`, then narrow and use that: ```ts function send(data: string) { const s = socket; if (s !== null) { queueMicrotask(() => s.send(data)); // ok: s is WebSocket, and const } } ``` This is not a trick to silence the compiler — it changes the meaning of the code, and in the safe direction. The closure now holds the socket that existed at check time, so a later reconnect cannot make the callback act on a different object or on `null`. If you genuinely want the *current* socket at invocation time, then the compiler is right to object, and the honest fix is to re-check inside the callback body: control-flow analysis restarts within that body, so `() => { if (socket !== null) socket.send(data); }` type-checks and is correct at runtime. Choosing between the two is the real content of the question: snapshot semantics versus live-read semantics. Silencing the error with an assertion picks neither and removes the compiler's ability to warn you when the invariant breaks.