Update: Add enforceForSwitchCase option to use-isnan

[mdjermanovic]

What is the purpose of this pull request? (put an "X" next to item)

[X] Changes an existing rule

Refs #12207

What rule do you want to change?

use-isnan

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

More if the option is set.

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

New option, which might be removed in major version to be new default behavior.

Please provide some example code that this change will affect:

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

switch (foo) {
    case NaN:
        bar();
        break;
    case 1:
        baz();
        break;
    // ...
}

What does the rule currently do for this code?

Nothing.

What will the rule do after it's changed?

Report warning.

case NaN is a possible error, basically the same as foo === NaN which the rule targets.

What changes did you make? (Give an overview)

New option.

Is there anything you'd like reviewers to focus on?

• The message in general. Also, there was an issue use-isnan should recommand using Number.isNaN #375 should the rule recommend Number.isNaN.
• The correct example in docs, is there a 'better' way to solve it?
• Should the same option also report switch (NaN)?

I'll submit another PR for .indexOf() and .lastIndexOf(), that should be a separate option (and stay as an option) as it can cause false positives due to the limitations, so someone might want to turn these off.

[mdjermanovic]

Marking as accepted as the issue #12207 is accepted.

[platinumazure]

LGTM, thanks!

[mdjermanovic]

I think that it would be also good to report switch(NaN), I just forgot that in the first commit.

[mysticatea]

• Covering switch(NaN) sounds good.
• About Number.isNaN, a rule like prefer-number-isnan may be useful?

[g-plane]

About Number.isNaN, a rule like prefer-number-isnan may be useful?

@mysticatea There are also something like preferring parseInt to Number.parseInt and preferring parseFloat to Number.parseFloat, so that rule shouldn't be only for Number.isNaN.

[mdjermanovic]

• Covering switch(NaN) sounds good.

I'll do this behind the same option, so please don't merge this PR yet :)

• About Number.isNaN, a rule like prefer-number-isnan may be useful?

I was asking for this particular rule, because in #375 was a discussion should the rule ever recommend Number.isNaN because it isn't available in all environments.

[mdjermanovic]

• Covering switch(NaN) sounds good.

This is done, and the option is now ready for a re-review.