no-null should allow, or have an option to allow, the `null == foo` pattern for value-presence-checking

A common pattern for checking for both undefined and null in a single operation is to intentionally use the coercive equality operator with null as the comparee:

if (foo == null)
   // ...

At the moment, this triggers the otherwise-wonderful no-null lint.

In the codebases I’ve worked on, this specific pattern is the only place that either:

1. coerceive equality, or
2. null

… is allowed. At least as far as I’m aware, that’s a common situation (those two being allowed in this specific pattern.)

Personally, despite the modern world with linting and TypeScript, I also still prefer yoda-comparisons; so I’d appreciate if this also allows (or the option also allows, if we add an option for this) the reversed version:

if (null == foo)
   // ...

I hope this Issue was helpful, and not just a waste of everyone’s time! 😅

[ELLIOTTCABLE]

1. “Where would you want it” - you can excise null from your own codebase (great!), but you should still be checking for it at API entrypoints. Code defensively!

2. “Better to test the two separately” - Well, yes, maybe, although that’s a matter of taste — two checks has a vanishingly minimal perf impact, of course; but mostly I’m of the camp that thinks that’s way, way too much text for a feature that’s explicitly built into the language (i.e. the explicit “checking for null and undefined, but no other values” expressed by that loose-comparison.)

   Saying ‘don’t use null == value because it’s less explicit’ feels a bit like saying ‘don’t use foo?.bar because if (typeof foo !== 'undefined' && foo !== null) { foo.bar } is more explicit’. That’s why we have syntactic sugar for common patterns! 😛

I won’t be offended if this isn’t to y’all’s tastes and you decide to close this, though. ¯\_(ツ)_/¯

[sindresorhus]

Can you not use if (foo != undefined) {} instead? It also matches null.