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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a --fix option for dot-notation #7014

Closed
not-an-aardvark opened this issue Aug 29, 2016 · 5 comments
Closed

Add a --fix option for dot-notation #7014

not-an-aardvark opened this issue Aug 29, 2016 · 5 comments
Labels
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 evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion rule Relates to ESLint's core rules

Comments

@not-an-aardvark
Copy link
Member

not-an-aardvark commented Aug 29, 2016

I'm using Node v6.4.0 and ESLint v3.4.0.

It would be useful to have an autofix option for the dot-notation rule. The rule currently reports cases where bracket notation can be safely replaced by dot notation; the fixer would go ahead and make that replacement.

var foo = bar["baz"];

// gets fixed to:

var foo = bar.baz;

The fixer could also replace invalid dot-notations (e.g. keywords when the {allowKeywords: false} option is set) with the bracket-notation counterpart.

/*eslint dot-notation: ["error", { "allowKeywords": false }]*/

var foo = bar.while;

// gets fixed to:

var foo = bar["while"];

If the brackets contain comments, I'm unsure of what the fixer should do. I suppose one option would be to extract the comment out:

var foo = bar[ /* AA */ "baz" /* BB */ ];

// gets fixed to:

var foo = bar /* AA */ .baz /* BB */ ;

...but that doesn't look very good. I think comments within bracketed properties are fairly rare anyway, so this might be okay. (Alternatively, we could refrain from fixing cases where the brackets contain a comment, but in that case it seems more consistent to not report those cases as errors either.)


I would be willing to add this if the issue is accepted.

edit: Added a section about fixing from dot-notation to bracket-notation with keywords.
edit: Added a section about what to do with comments.

@eslintbot eslintbot added the triage An ESLint team member will look at this issue soon label Aug 29, 2016
@platinumazure platinumazure added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion and removed triage An ESLint team member will look at this issue soon labels Aug 29, 2016
@mysticatea
Copy link
Member

Sounds very good to me.
👍

@pmcelhaney
Copy link
Contributor

Is there a general guideline for what a fixer should do if comments interfere? That seems to be a common problem.

My preference would be to not automatically fix code that involves comments. It doesn't hurt anyone to require human intervention in those rare cases.

@vitorbal
Copy link
Member

@pmcelhaney if i understood your question correctly, this might be related: #5958 (comment)
TL;DR we won't autofix when a comment interferes

@nzakas
Copy link
Member

nzakas commented Sep 3, 2016

Seems reasonable. 👍

To echo what @vitorbal said, if we can't be 100% correct with the fix, we shouldn't attempt it. So in the case of comments, we should just skip that.

not-an-aardvark added a commit to not-an-aardvark/eslint that referenced this issue Sep 3, 2016
not-an-aardvark added a commit to not-an-aardvark/eslint that referenced this issue Sep 4, 2016
not-an-aardvark added a commit to not-an-aardvark/eslint that referenced this issue Sep 4, 2016
@platinumazure
Copy link
Member

👍 from me, now we just need a champion.

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 6, 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 Feb 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
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 evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion rule Relates to ESLint's core rules
Projects
None yet
Development

No branches or pull requests

7 participants