Syntactic checks against comparing to null/undefined in strictNullChecks mode

[lauraharker]

🔍 Search Terms

nullish, strictNullChecks, equals, undefined, null

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When strictNullChecks are enabled, disallow == and === comparisons to null/undefined for expressions that are syntactically known to not be undefined.

I'd imagine the definition of syntactically not null/undefined expressions would be similar to that from #59217.

This is similar to #11920, but I think would be easier to land because it won't error on defensive programming null checks.

📃 Motivating Example

TypeScript's typeof operator always returns a string, but it can be hard to spot the difference between checking "undefined" and just undefined in code like this:

if (typeof foo === undefined) {

In strictNullChecks mode, TypeScript will catch unnecessary comparisons like this, for expressions that at runtime it knows can never be null or undefined.

💻 Use Cases

1. What do you want to use this for? catch user errors
2. What shortcomings exist with current approaches? there's the https://typescript-eslint.io/rules/no-unnecessary-condition/, but that's type-based so does have the problem of flagging defensive programming. it's also nice to have things be in the compiler instead of a separate tool.
3. What workarounds are you using in the meantime? nothing at the moment, if this is infeasible will probably create a custom lint check.

[MartinJohns]

Duplicate of #29200.

[lauraharker]

I'd argue this is broader in scope than #29200. Typeof was the motivating example, but TS could also check other code patterns as it does for nullish coalesing after #59217.

[MartinJohns]

I mean.. the other cases are covered by #11920.

[lauraharker]

My understanding is that a major concern about #11920 was breaking code intentionally checking for null/undefined against an API excluding null/undefined.

We intentionally allow this for the sake of defensive programming (i.e. defending against missing inputs from non-TS code). If there's enough demand we could add a flag or something.

& the discussion on the PR to fix that issue #59559 (comment) seems to be concluding that it's too breaking to land without adding an extra flag.

I'd expect this change to be significantly less breaking specifically because it would be syntactic only.

If the TS team is interested in rescoping #11920 to be about cases only syntactically known to be not null/undefined, or doesn't want to add a syntactic-only check, I understand, but I would like to get feedback specifically on the idea of a syntactic-only check so that it's not lost in the noise in #11920.

[lauraharker]

To clarify, I'm not proposing to flag this code from #11920 (comment):

declare const value: number;
if (value !== null) { // <-- somehow valid, expected to be invalid, since number doesn't have null as a possible value
}
if (value !== '') { // <-- invalid as expected 
}

because value is not syntactically known to always be null, that's just a type system construct.

[lauraharker]

Other cases that could be covered, motivated by the nullish coalesce checks from #59217:

if (((x) => x) !== undefined) {}
if ("" !== undefined) {}
if ({foo: 3} !== undefined) {}

[RyanCavanaugh]

I think this is a decent idea now that we have a notion of "syntactically provable to not be undefined". I put up a very drafty draft at #60433 to see if this is likely to be useful.