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
Update: Report assignment expression location in no-cond-assign #12465
Conversation
Is there a reason why the IfStatement node is the reported node? It seems to me that we should just always report the AssignmentExpression. |
Sorry, the PR description was confusing, that's exactly what this PR does - reports the 'invalid' I agree there is no reason to report |
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'm using this review to try to explain what I'm getting at a little better. (Please refer to the inline comment)
lib/rules/no-cond-assign.js
Outdated
@@ -106,7 +106,7 @@ module.exports = { | |||
|
|||
context.report({ | |||
node, | |||
loc: node.test.loc.start, | |||
loc: node.test.loc, |
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 assume that if we are reporting the node.test
location (node.test.loc
), then node.type === "IfStatement"
.
Why not just report node: node.test
(on line 108)? Then the code automatically uses the location of that node (i.e., node.test.loc
) when preparing the lint report.
I don't think we are getting any value in reporting on the IfStatement but setting the location equal to the AssignmentExpression's location.
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.
Ah, sorry I didn't understand the first time!
Since the rule targets the assignment, I completely agree. I'm not sure why was the IfStatement
reported. Maybe because the message is "Expected a conditional expression and instead saw an assignment."
. There is a following comment in the code:
// must match JSHint's error message
missing: "Expected a conditional expression and instead saw an assignment."
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.
#4040 might be relevant to this question. The loc
was added to point to the test
node instead of just changing the reported node to the test
node. I'm not sure why.
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.
The changes in this PR indeed look really unusual compared to all other rules.
Looks much better to simply report the AssignmentExpression
node, as you suggested.
I'll modify this, which will change nodeType
in the linting output, I guess that isn't information of particular importance?
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.
This is done now.
I think this could be accepted as a bug fix, personally. |
Agree. This should be bug fix or chore. |
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! Mind fixing up the merge conflicts so we can land this?
6d56878
to
2349e27
Compare
Rebased and fixed now |
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!
One last question before we merge this - it looks like the consensus is to accept this as a bug fix. It seems to me like it should still be considered a semver-minor change because it can lead to more errors in the case described in the original description. Thoughts? |
What is the purpose of this pull request? (put an "X" next to item)
[X] Changes an existing rule
What rule do you want to change?
no-cond-assign
- changes just reported locations.Does this change cause the rule to produce more or fewer warnings?
In general, the same.
But, if we consider
eslint-disable
comments, in some cases with thealways
option this change can produce more or fewer warnings because the reported line could change.How will the change be implemented? (New option, new default behavior, etc.)?
New default behavior
Please provide some example code that this change will affect:
What does the rule currently do for this code?
The default
"except-parens"
option and the"always"
option have completely different implementations, and the reported locations are quite different.The default
"except-parens"
option reports just thestart
location of the test node (which is an assignment expression). This highlights only the first token (or nothing in the online demo).The
always
option highlights the wholeif
node.What will the rule do after it's changed?
Always report the location of the assignment expression, with both start and end.
What changes did you make? (Give an overview)
Changed reported locations for both options.
Is there anything you'd like reviewers to focus on?
This change can produce more warnings when the option is
always
and the first line is disabled and the assignment is not on the first line.