Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use-isnan options for implicit Strict Equality Comparison #12207

Assignees

Comments

@mdjermanovic
Copy link
Member

@mdjermanovic mdjermanovic commented Sep 3, 2019

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:

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

This comment has been minimized.

Copy link
Member

@mysticatea mysticatea commented Sep 4, 2019

Thank you for this issue.

Sounds a good idea.

@platinumazure

This comment has been minimized.

Copy link
Member

@platinumazure platinumazure commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Contributor

@ljharb ljharb commented Sep 4, 2019

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

@mdjermanovic

This comment has been minimized.

Copy link
Member Author

@mdjermanovic mdjermanovic commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Member Author

@mdjermanovic mdjermanovic commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Member

@g-plane g-plane commented Sep 9, 2019

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

@mdjermanovic

This comment has been minimized.

Copy link
Member Author

@mdjermanovic mdjermanovic commented Oct 2, 2019

I'm working on this (indexOf).

mdjermanovic added a commit that referenced this issue Oct 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.