Syntactic checks against comparing to null/undefined in strictNullChecks mode

🔍 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 https://github.com/microsoft/TypeScript/pull/59217.

This is similar to https://github.com/microsoft/TypeScript/issues/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.

Revisa el comportamiento propuesto junto con el issue #11920 y el pull request #59217, que definen enfoques relacionados para expresiones sintácticamente conocidas como no nullish. Se considera terminado cuando strictNullChecks informa de las comparaciones innecesarias de null/undefined solicitadas sin cambiar el JavaScript generado ni el comportamiento en tiempo de ejecución.