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
feat: add suggestions to use-isnan
in binary expressions
#17996
feat: add suggestions to use-isnan
in binary expressions
#17996
Conversation
✅ Deploy Preview for docs-eslint canceled.
|
tests/lib/rules/use-isnan.js
Outdated
{ | ||
code: `/* just | ||
adding */ x /* some */ === /* comments */ NaN; // here`, | ||
errors: [{ | ||
...comparisonError, | ||
suggestions: [{ | ||
messageId: "replaceWithIsNaN", | ||
output: `/* just | ||
adding */ Number.isNaN(x); // here` | ||
}] | ||
}] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure what to do with the comments here, so I left the default behavior for now.
Any direction on what's the expected behavior here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks okay to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it OK to lose some comments when fixing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question -- ideally we don't lose any comments, but since this is a suggestion, I think it's okay because people will manually need to accept it and can always undo it if it's a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a similar case in ts-eslint, and there we've decided to aggregate all of the comments and throw them somewhere above the code.
Do you think it's worth doing the same here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think it's okay for suggestions to just remove comments that happen to be there. As @nzakas noted, if it's a problem in some cases, user can undo the change and manually fix the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this. The functionality for the equality operators looks good.
We shouldn't supply suggestions for comparison operators like <
and >
. Because this isn't an equality operation, we can't use isNaN()
as a replacement for those.
You say this partially handles #17978 but you didn't indicate what part you are addressing and what part(s) you're not. Can you please update the description of the PR to explain what specifically you are addressing from the issue?
tests/lib/rules/use-isnan.js
Outdated
{ | ||
code: `/* just | ||
adding */ x /* some */ === /* comments */ NaN; // here`, | ||
errors: [{ | ||
...comparisonError, | ||
suggestions: [{ | ||
messageId: "replaceWithIsNaN", | ||
output: `/* just | ||
adding */ Number.isNaN(x); // here` | ||
}] | ||
}] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks okay to me.
Done
Yeah, sure, sorry for that. Updated 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Would like another approval before merging.
const foo = "bar";
Number.isNaN(foo); // false
isNaN(foo); // true
Number.isNaN(Number(foo)); // true The same for |
I'm not sure we can assume the user intent (Well... yeah, we basically assume the intent by giving those suggestions, so... 😅), but if I understand correctly, this makes sense. Not sure though... Maybe we can suggest both and leave the choice to the user? WDYT? |
By both, you mean |
Yup, exactly |
I think it's fine to leave two suggestions, one for each, though I would put |
Added 2 suggestions support. |
tests/lib/rules/use-isnan.js
Outdated
{ | ||
code: "123 === NaN;", | ||
errors: [comparisonError] | ||
errors: [{ | ||
...comparisonError, | ||
suggestions: [ | ||
{ | ||
messageId: "replaceWithIsNaN", | ||
output: "Number.isNaN(123);" | ||
}, | ||
{ | ||
messageId: "replaceWithCastingAndIsNaN", | ||
output: "Number.isNaN(Number(123));" | ||
} | ||
] | ||
}] | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For ===
or !==
, I think there should be only one suggestion (without Number()
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, yeah, this makes more sense. Now I get what you mean.
Done :)
I think it's fine because a code like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! Leaving open for @nzakas to re-verify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Nice work!
@StyleShit we'd like to pay you for this contribution, but I couldn't find an email address to send you the details. Can you please contact us at contact (at) eslint (dot) org? Thanks. |
Partially handles #17978
This PR adds support for fix suggestions in
use-isnan
only in binary expressions, so this:will be fixed to this: