Javascript: Conflicting rule: Comparison Operators & Equality

[progre]

https://github.com/airbnb/javascript/blob/master/README.md#comparison--eqeqeq

It can be read like to completely prohibite == and !=, but linter accept it.
https://github.com/airbnb/javascript/blob/57ff032b0740ba2a46af4bc40cf5638a3e62a365/packages/eslint-config-airbnb-base/rules/best-practices.js#L40

Which do you recommend?
if (object == null) { ... } or if (!object) { ... }

[ljharb]

The guide is strict - it dictates only using ===/!==.

The linter is intentionally a bit looser - in that it allows == null/!= null.

There is only two reasons this is the case: it's a good practice to treat null and undefined as the same; and undefined can be redefined (ES5 only prevents it from being redefined in the global scope), so === undefined isn't safe, and typeof x === 'undefined' || x === null is a bit verbose.

What's recommended for an "if" check depends on what the condition is guarding - if it would fail only for null, use x === null; if only for undefined, use typeof x === 'undefined; if for null or undefined, use x == null; and if for any falsy value (including false, the empty string, NaN, and 0), use !x. In other words, your condition should be exactly as precise as the semantic needs of the block being guarded.

[progre]

I understood that it mean to accept to distinguish null or undefined and any falsy value.

I was satisfied. Thank you!

[alecmev]

This is a reply to https://github.com/airbnb/javascript/issues/60#issuecomment-394792680:

When are you checking for _just_ undefined such that == null isn’t ideal?

I write TS, and Foo | undefined types are all over the place, so when a valid value of Foo may be falsy, I just compare it against undefined. It's an intuitive thing to do, to narrow it like that; != null would be out of place. But even in vanilla JS, if docs say that an API is supposed to return either a Foo or undefined, why would I involve null?

If some piece of software likes to deal with CanBeFalsyType | undefined | null, and x !== undefined && x !== null starts to really bother people, then I'd rather sacrifice some perf and have an isMaybe helper, than exploit implicit coercion with != null / != undefined. So easy to mistype !== as !=, and the other way around (which is especially important in vanilla JS, where there's no static type checking to catch the un-narrowed undefined). And not only is this typo-prone, it may fool a sleepy reader too.