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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update: Add autofix for sort-vars #9496

Merged
merged 2 commits into from
Nov 26, 2017

Conversation

trevinhofmann
Copy link
Contributor

@trevinhofmann trevinhofmann commented Oct 21, 2017

What is the purpose of this pull request?

  • Add autofixing to a rule

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 to var a, b, c and var b = 3, a = true to var a = true, b = 3 but will not fix var b = f(), a = g() or var b = 5, a = b.

Is there anything you'd like reviewers to focus on?

All of it, please 馃槙

@eslintbot
Copy link

LGTM

Copy link
Member

@aladdin-add aladdin-add left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this intentional?

Copy link
Contributor Author

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;

Copy link
Member

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:

  1. Avoid any fixes that could change the runtime behavior of code and cause it to stop working.
  2. Make fixes as small as possible. Fixes that are unnecessarily large could conflict with other fixes, and prevent them from being applied.
  3. Only make one fix per message. This is enforced because you must return the result of the fixer operation from fix().
  4. 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.

Copy link
Contributor Author

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?

Copy link
Member

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]
Copy link
Member

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;

currenVariableName = currenVariableName.toLowerCase();
}
if (currentVariableName < lastVariableName) {
if (unfixable || fixed) {
Copy link
Member

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.)

Copy link
Contributor Author

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.

@aladdin-add aladdin-add added enhancement This change enhances an existing feature of ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion rule Relates to ESLint's core rules labels Oct 22, 2017
@eslintbot
Copy link

LGTM

@platinumazure
Copy link
Member

I would love to see the reporting logic be simplified to reporting one error per VariableDeclaration-- but eventually, and not in this PR. 馃槃

@trevinhofmann
Copy link
Contributor Author

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. 馃槂

Copy link
Member

@aladdin-add aladdin-add left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@ilyavolodin
Copy link
Member

@eslint/eslint-team Does anyone else wants to support this enhancement?

@trevinhofmann
Copy link
Contributor Author

If this does get merged, I would gladly submit a second PR to simplify the logic a bit and report only one error.

@platinumazure
Copy link
Member

@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).

@aladdin-add aladdin-add self-assigned this Nov 23, 2017
@aladdin-add aladdin-add added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Nov 23, 2017
Copy link
Member

@platinumazure platinumazure left a 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.

@not-an-aardvark not-an-aardvark merged commit 5619910 into eslint:master Nov 26, 2017
@not-an-aardvark
Copy link
Member

Thanks for contributing!

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators May 26, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label May 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants