-
-
Notifications
You must be signed in to change notification settings - Fork 5k
use-isnan options for implicit Strict Equality Comparison #12207
Copy link
Copy link
Closed
Closed
Copy link
Labels
acceptedThere is consensus among the team that this change meets the criteria for inclusionThere is consensus among the team that this change meets the criteria for inclusionarchived due to ageThis issue has been archived; please open a new issue for any further discussionThis issue has been archived; please open a new issue for any further discussionenhancementThis change enhances an existing feature of ESLintThis change enhances an existing feature of ESLintruleRelates to ESLint's core rulesRelates to ESLint's core rules
Metadata
Metadata
Assignees
Labels
acceptedThere is consensus among the team that this change meets the criteria for inclusionThere is consensus among the team that this change meets the criteria for inclusionarchived due to ageThis issue has been archived; please open a new issue for any further discussionThis issue has been archived; please open a new issue for any further discussionenhancementThis change enhances an existing feature of ESLintThis change enhances an existing feature of ESLintruleRelates to ESLint's core rulesRelates to ESLint's core rules
What rule do you want to change?
use-isnanThis rule targets
foo === NaN(Strict Equality Comparison)(also targets
!==,==and!=)Currently, the rule checks only
BinaryExpressionnodes, i.e. only explicit comparisons.This is a proposal to also check the following:
case NaNwill never match and it's a possible error.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 arefalse.How will the change be implemented? (New option, new default behavior, etc.)?
2 options,
enforceForSwitchCaseandenforceForIndexOf.Please provide some example code that this change will affect:
What does the rule currently do for this code?
Nothing.
What will the rule do after it's changed?
Are you willing to submit a pull request to implement this change?
Yes. (there is PR #12106 for
enforceForSwitchCase)