Enforce use of non-strict equality (==/!=) when comparing to null

[sstur]

Right now I use eqeqeq to enforce strict (===) equality everywhere, except when comparing to null. That is great, but I actually want to go one step further and enforce non-strict (==) equality when comparing any value to null literal.

To put it another way, this will NOT currently throw any lint warning:

let foo;
console.log('is it null', foo == null);
console.log('is it really null', foo === null);

Those two statements are not easy to tell apart during code review. The issue can arise that a coder will use strict equality out of habit yet (in our codebase) they should always use loose equality when comparing to null in order to also catch undefined. Similar code will pass lint and pass tests and then later it might fail in production when undefined sneaks in somehow. I'd like to statically enforce loose equality for null.

Would you be open to a PR?

[mysticatea]

Thank you for this issue.

As far as I know, there is no rule to enforce foo == null in core rules (eqeqeq rule has options to allow foo == null, though).
I think such option or a rule is reasonable.

@eslint/eslint-team what do you think?

[platinumazure]

Something like an "except-null" option for eqeqeq? I could get on board with that.

[mikesherov]

This would match JSHint eqnull. 👍

[btmills]

We have "allow-null" that permits but does not require == null, so I think "except-null" makes sense. 👍 I'm willing to champion.

[platinumazure]

If @mysticatea is on board, I count a champion and two (non-champion) 👍's. (Not counting myself.)

[nzakas]

I'll 👍 with the caveat that we need a better option name. We've tried to stay away from using the word "except" because it's unclear what it means. Especially since we have "allow-null", i don't think "except-null" is clear at all.

@sstur we will happily accept a PR once we get the option name figured out.

[platinumazure]

Some thoughts on option name:

• require-loose-if-null
• loose-if-null
• no-strict-if-null

Let's iterate...

[nzakas]

If you go for more than two words, then that should become a property option:

eqeqeq: ["error", {
    someLongOption: true
}];

I'd strongly suggest you avoid "loose" and "strict" as descriptions since those are also modes (loose or nonstrict mode and strict mode) for executing JavaScript.

[platinumazure]

@nzakas Good points about loose/strict. Regarding an option object key, one issue is that this option cannot be specified in conjunction with "allow-null".

I could see something like this though:

{
    "eqeqeq": ["error", { "eqeqForNull": "allow|always|never" }]
}

Where the default is "never" and the current string option "allow-null" is soft-deprecated and equivalent to "allow" in the new option. Then "always" represents the functionality requested in this issue.

We can continue to iterate on the option name, but is this better?

[btmills]

Having a named property with "allow" (or "either"?) /always/never" seems like the most explicit. Other options "eqeqNull" or "doubleEqualsNull" (or even "==null", though that would require quotes in yml and js configs).

[mysticatea]

Thank you, everyone!

There was "never-null" option (means "never use eqeqeq for null") in my head. But object-form option seems better.

By the spec, "smart" option is handling 3 things.

• Comparing two literal values
• Evaluating the value of typeof
• Comparing against null

http://eslint.org/docs/rules/eqeqeq#smart

What about the following object-form options:

{
    "eqeqeq": ["error", {
        "eqeqNull": "never" | "always" | "allow",
        "eqeqTypeof": "never" | "allow",
        "eqeqBetweenLiterals": "never" | "allow"
    }],
    // Or shorthands:
    "eqeqeq": ["error", "always" | "smart" | "allow-null"],
}

• eqeqNull - the setting for non-strict equality comparison with null
  (such as a == null)
  • "never" (default) - disallows == with null.
  • "always" - enforces == with null. (this is the new behavior)
  • "allow" - allows == with null.
• eqeqTypeof - the setting for non-strict equality comparison with typeof operator
  (such as typeof a == "number")
  • "never" (default) - disallows == with typeof operator.
  • "allow" - allows == with typeof operator.
• eqeqBetweenLiterals - the setting for non-strict equality comparison between literals
  (such as 100 == 200)
  • "never" (default) - disallows == between lterals.
  • "allow" - allows == between literals.

Shorthands:

	eqeqNull	eqeqTypeof	eqeqBetweenLiterals
"always" (default)	never	never	never
"smart"	allow	allow	allow
"allow-null"	allow	never	never

[nzakas]

I don't think we should use "eqeq" in option names as it's the opposite of the rule. "always" , "never", etc. Should mean "always use ===" and "never use ===".

It might be easiest to deprecate allow-null in favor of an options object:

eqeqeq: [error, always, {
    null: always | never | ignore
}]

Where "ignore" is equivalent to allow-null

[alberto]

👍 what @nzakas said

[btmills]

👍 to @nzakas's idea.

Would that just be for null, or would it also have options for typeof and literals as covered by "smart"?

[mysticatea]

Sounds good. Indeed, opposite options were confused.

[sstur]

Thanks @nzakas. That makes perfect sense. I'll work on a PR for that.

@btmills: My issue is purely with null since that has a distinct behavioral difference between == and === that we care about in our codebase. For everything else, I always enforce === regardless of typeof or comparing two primitive literals.

Comparing typeof foo === 'something' is just comparing a string to a string so I don't expect our coders to remember an exception for that. I just explain "Always use strict equality. Except when comparing to null in which case do NOT use strict equality."

[btmills]

@sstur Just checking in, how are things coming along? Is there anything I can do to help?

[nzakas]

@btmills I'd say let's stick with "null" for now. If we get further requests for configuration, we can always add more options. I'm the meantime, we can have this new option only work with "always".

[btmills]

let's stick with "null" for now

👍 works for me

[mysticatea]

👍

[nzakas]

@sstur are you still working on this?

[sstur]

Hi @nzakas and @btmills. Thanks for all the input and sorry for the delay. I am working on this now. I expect to get a PR out early this week.

The plan as I understand it is:

deprecate allow-null in favor of an options object.

eqeqeq: [error, always, {
    null: always | never | ignore
}]

Where "ignore" is equivalent to allow-null

we can have this new option only work with "always"

So to summarize:

• always -> This will mean what it always has, but it will accept an options object. If the options object is omitted it will be as if you passed {null: "never"}.
• smart -> This will mean what it always has and not accept any options.
• allow-null -> This will be deprecated in favor of "always", {null: "ignore"}

I will proceed with that plan. Thanks!

[nzakas]

@sstur correct. Thanks!