-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update: Add autofix for sort-vars
#9496
Update: Add autofix for sort-vars
#9496
Conversation
LGTM |
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 contribution! just left a few comments.
{ | ||
code: "var c, d, a, b", | ||
output: "var a, b, c, d", | ||
errors: 2 |
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 this intentional?
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.
Yes, this test case was already included; I only expanded it and added the expected fixed output
.
It is expected to have two errors per the documentation:
Alphabetical list is maintained starting from the first variable and excluding any that are considered problems. So the following code will produce two problems:
var c, d, a, b;
But this one, will only produce one:
var c, d, a, e;
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.
Do you mean this: errors: [expectedError, expectedError]
I prefer reporting one error. see here:https://github.com/eslint/eslint/blob/master/docs/developer-guide/working-with-rules.md#applying-fixes
Best practices for fixes:
- Avoid any fixes that could change the runtime behavior of code and cause it to stop working.
- Make fixes as small as possible. Fixes that are unnecessarily large could conflict with other fixes, and prevent them from being applied.
- Only make one fix per message. This is enforced because you must return the result of the fixer operation from
fix()
.- Since all rules are run again after the initial round of fixes is applied, it's not necessary for a rule to check whether the code style of a fix will cause errors to be reported by another rule.
- For example, suppose a fixer would like to surround an object key with quotes, but it's not sure whether the user would prefer single or double quotes.
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 a little confused. Are you suggesting that the rule's functionality be changed to only report one error?
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 guess reporting one error can simplify the code to 3 steps:
check is sorted => check is safe to fix => do fix
.
maybe just my personal preference, I don't feel strong.
hmm. sorry! I forgot this is the original functionality. not a good idea!~ 馃憥
{ | ||
code: "var b=10, a=b;", | ||
output: null, | ||
errors: [expectedError] |
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.
could you please add some more tests:
e.g.
var b = 0, a = `${b}`;
var b = 0, a = `${f()}`
var b = 0, c = b, a;
var b = 0, c = 0, a = b + c;
var b = f(), c, d, a;
var b = `${f()}`, c, d, a;
lib/rules/sort-vars.js
Outdated
currenVariableName = currenVariableName.toLowerCase(); | ||
} | ||
if (currentVariableName < lastVariableName) { | ||
if (unfixable || fixed) { |
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.
Nitpick: maybe it make more sense to place this check to fixer function. (returning null means do not fix.)
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! I did not know about returning null in a fixer. I will change this.
LGTM |
I would love to see the reporting logic be simplified to reporting one error per VariableDeclaration-- but eventually, and not in this PR. 馃槃 |
Agreed @platinumazure and @aladdin-add - I would prefer simplified logic that reports only one error, but I did not want to change that functionality in this PR. 馃槂 |
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!
@eslint/eslint-team Does anyone else wants to support this enhancement? |
If this does get merged, I would gladly submit a second PR to simplify the logic a bit and report only one error. |
@eslint/eslint-team This just needs a champion and then we can accept. Otherwise, we should probably close this soon (though I really hope we don't). |
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 I'm okay with this approach, but I don't know if we have precedent with having multiple lint messages return a fixer that's conditional on whether a closure variable has been set or not. But then again, it's really hard conceptually to have a "simple" design around a rule that needs to basically report individual VariableDeclarator nodes for users when autofix isn't on, and report/fix the VariableDeclaration when autofix is on. So there probably isn't a better way to do this given rules can't know if autofix is on or not. But this might be worth revisiting/refactoring later.
Thanks for contributing! |
What is the purpose of this pull request?
What changes did you make?
The
sort-vars
rule can now automatically fix unsorted variable declarations when each variable is either unassigned or assigned to a literal value. I added the implementation for this fixer, test cases to validate that the fixer works as expected, and test cases to validate that it does not fix when a variable is assigned to a non-literal value.In short, the fixer will convert
var c, b, a
tovar a, b, c
andvar b = 3, a = true
tovar a = true, b = 3
but will not fixvar b = f(), a = g()
orvar b = 5, a = b
.Is there anything you'd like reviewers to focus on?
All of it, please 馃槙