Never-initialized variable type is not narrowed to undefined

[jtbandes]

🔎 Search Terms

narrow uninitialized, uninitialized undefined

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about initialized/uninitialized

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.0-dev.20250326#code/MYewdgzgLgBAZiEMC8MAUUDuIBcNoBOAlmAOYCUeAbiEQCYoB8MA3gFAwwBEArhAKb4oxYFC4BuDjCkB6GTH4QANiSgBaOkQgBDAEZL+asPwAe6lcZgABKAE8ADouDF76xRagySRdXX7AlbQJtKCJwCCkDWHB+PEISUhgAHxgeMD84En46SSkiOHQYlGRULBByVilOORgAPQB+KpgagDlEeykAXzZutgQQNC4ucnEgA

💻 Code

const foo = (two: string): void => {
  "use strict";
  
  // eslint-disable-next-line @typescript-eslint/init-declarations
  let one: string | undefined;

  if (one === two) {
    // ^?  let one: string | undefined
    // Noop
  }
}

foo("");

🙁 Actual behavior

The type is not narrowed, which prevents typescript-eslint from flagging this comparison that always fails: typescript-eslint playground

🙂 Expected behavior

The one === two comparison should be flagged because it always returns false (there is no way one has any value other than undefined).

Additional information about the issue

Also filed a related issue with ESLint: eslint/eslint#19581

[RyanCavanaugh]

You're always allowed to compare to undefined, see #11920

I believe not narrowing here is a concession to #9998 to reduce false positives when assignments occur outside TS's immediate CFA

[jtbandes]

You're always allowed to compare to undefined, see #11920

That makes sense – I guess I would expect this part to be flagged by typescript-eslint rather than TS itself, however due to the lack of narrowing it is not flagged.

[kirkwaiblinger]

Noting that this does have observable impact within TS, too, though, not just for tooling, for example:

let alwaysUndefined: string | undefined;
let foo = alwaysUndefined?.toLocaleString(); // allowed (but bad code)
export {}

let alwaysUndefined: string | undefined = undefined;
let foo = alwaysUndefined?.toLocaleString(); // TS ERROR
export {}

[kirkwaiblinger]

When the let variable is captured in closures and reassigned the existing behavior definitely seems reasonable, but I'd think in theory TS could safely analyze the never-captured, never-reassigned variable as simply undefined. Might have some confusing/negative repercussions for user experience if adding closure let reassignments can alter typechecking at a distance though.