In TypeScript 5.5 or later, `if (isDefined(v)) { v.trim(); }` narrows `v` when the helper is written `function isDefined(x: string | undefined) { return x !== undefined; }`, but reports that `v` may be undefined once you annotate that helper's return type as `: boolean`. What is going on?

## Why extracting a check used to break narrowing TypeScript's narrowing is a *control-flow* analysis performed within a single function body. It watches the conditions your code branches on and refines the types of references it can see. It is not interprocedural: the checker does not inline a helper's body to work out what its `true` result implies about the argument you passed. So for most of TypeScript's history, this was a hard boundary: ```ts function isDefined(x: string | undefined) { return x !== undefined; } function use(v: string | undefined) { if (isDefined(v)) { v.trim(); // pre-5.5 error: 'v' is possibly 'undefined' } } ``` The signature said `(x: string | undefined) => boolean`. A boolean carries no information about *which* argument it is a statement about, so the call site had nothing to narrow with. The long-standing remedy was to declare a type predicate in the return position, which makes the relationship explicit in the signature. ## What TypeScript 5.5 added TypeScript 5.5 infers those predicates in the common cases. When checking a function without a return-type annotation, the compiler asks whether the body is simply a refinement of one of its parameters; if so, it synthesises a predicate signature. `isDefined` above is inferred as `(x: string | undefined) => x is string`, and the call site narrows exactly as if you had written the predicate yourself. The headline consequence is that ordinary array pipelines type themselves: ```ts const raw = [1, 2, 3].map(n => (n % 2 === 0 ? n : null)); const evens = raw.filter(n => n !== null); // number[] in 5.5+, (number | null)[] before ``` ## The conditions for inference The inference is deliberately narrow, because a wrong predicate is worse than no predicate — it hands the checker a promise it will trust without re-checking. - **No explicit return type.** If you write `: boolean`, the compiler takes your annotation as the signature. An annotation is a declaration of intent, and the compiler does not second-guess it. This is the specific behaviour in the question. - **Exactly one `return`, and no implicit returns.** A body with an early `return false` and a later `return true` is not analysed, even though a human can see it is equivalent. An arrow function with an expression body counts as the single return. - **The parameter is not mutated.** If the body assigns to the parameter, the expression being returned may be about a different value than the caller passed, so the relationship no longer holds. - **The returned expression must refine that parameter.** The compiler works out the type the parameter has when the expression is `true`; if that type is narrower than the declared one, it becomes the predicate. ```ts function a(x: string | undefined) { return x !== undefined; } // x is string function b(x: string | undefined): boolean { return x !== undefined; } // plain boolean function c(x: string | undefined) { // plain boolean if (!x) return false; return true; } function d(x: string | undefined) { // plain boolean x = x ?? ""; return x !== undefined; } ``` ## What this does and does not buy you A predicate — inferred or declared — is a *promise the compiler trusts*. Types are erased, so there is no verification at run time and no cost either: the emitted JavaScript is just your comparison. If the body's logic is wrong, or if you later change the body without changing the (now explicit) annotation, the checker keeps narrowing on a false premise and you get a crash where the type said you could not. There is also a subtle refactoring hazard in the inference itself. Because the predicate is *inferred*, it is not written anywhere. Adding an early return to the helper for an unrelated reason silently downgrades the signature to `boolean`, and the errors appear in every caller rather than at the change. Nothing in the helper's own file complains. ## How to reason about it in review When someone reports "my check stopped narrowing after I extracted it", run the list: is there a return-type annotation, is there more than one return, does the body assign to the parameter, and does the returned expression actually refine the parameter rather than some derived value? If the narrowing genuinely matters to callers, the honest move is to state the relationship in the signature rather than depend on an inference that a future edit can remove without warning.