use-isnan options for implicit Strict Equality Comparison

[mdjermanovic]

What rule do you want to change?

use-isnan

This rule targets foo === NaN (Strict Equality Comparison)

(also targets !==, == and !=)

Currently, the rule checks only BinaryExpression nodes, i.e. only explicit comparisons.

This is a proposal to also check the following:

• CaseClauseIsSelected internally performs Strict Equality Comparison, so case NaN will never match and it's a possible error.
• Array.prototype.indexOf also uses Strict Equality Comparison, so foo.indexOf(NaN) will never match and it's a possible error. The same applies to Array.prototype.lastIndexOf.

Does this change cause the rule to produce more or fewer warnings?

More if an option is set to true. Defaults are false.

How will the change be implemented? (New option, new default behavior, etc.)?

2 options, enforceForSwitchCase and enforceForIndexOf.

Please provide some example code that this change will affect:

/*eslint use-isnan: "error"*/

switch (foo) {
    case NaN:
        bar();
        break;
}

foo.indexOf(NaN);
foo.lastIndexOf(NaN);

What does the rule currently do for this code?

Nothing.

What will the rule do after it's changed?

/*eslint use-isnan: ["error", {"enforceForSwitchCase": true}]*/

switch (foo) {
    case NaN: // error
        bar();
        break;
}

/*eslint use-isnan: ["error", {"enforceForIndexOf": true}]*/

foo.indexOf(NaN); // error
foo.lastIndexOf(NaN); // error

Are you willing to submit a pull request to implement this change?

Yes. (there is PR #12106 for enforceForSwitchCase)

[mysticatea]

Thank you for this issue.

Sounds a good idea.

[platinumazure]

I'm definitely 👍 for case clauses.

I'm less sure about indexOf just due to lack of strong typing, but I won't oppose that (and I acknowledge that we have precedent with other Array.prototype functions).

[ljharb]

it’d be better to make a custom rule forbidding indexOf in favor of includes, for that one.

[mdjermanovic]

I'm less sure about indexOf just due to lack of strong typing, but I won't oppose that (and I acknowledge that we have precedent with other Array.prototype functions).

The initial idea was one option for both, but exactly because of this user should have a way to disable indexOf check. I think it's still useful in most cases, but has to be always behind an option (unlike case clauses, which could be default behavior in next major version).

[mdjermanovic]

it’d be better to make a custom rule forbidding indexOf in favor of includes, for that one.

This can be easily done with no-restricted-properties. Or probably with no-restricted-syntax to disable just === -1, >= 0 etc. for which includes is equvalent.

[g-plane]

Off topic:
eslint-plugin-unicorn has a rule to advise to use Array.prototype.includes.

[mdjermanovic]

I'm working on this (indexOf).