eslint: 'no-unless-return' rule's fix is not fix but destroying.

Tell us about your environment

ESLint Version: 3.13.1
Node Version: 7.4.0
npm Version: 4.1.1

What parser (default, Babel-ESLint, etc.) are you using?

Please show your full configuration:

module.exports = {
  extends: 'airbnb',
  rules: {
    'no-unused-vars': ['error', { vars: "all", args: 'none' }],
  }
}

What did you do? Please include the actual source code causing the issue.

function foo(key) {
  var value = map[key];
  if(!value){
    return;
  }
  // do something....
}
=>
function foo(key) {
  var value = map[key];
  if(!value){
  }
  // do something....everytime???
}

What did you expect to happen?

What actually happened? Please include the actual, raw output from ESLint.

I do not want you to change the logic by ‘–fix’ option.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 2
Comments: 17 (13 by maintainers)

Most upvoted comments

FWIW, Atom’s linter-eslint now supports specifying rules not to auto-fix in version 8.1.0.

IanVS on Jan 30, 2017

@not-an-aardvark while I understand your rationale, we do have to be sensitive to how ESLint is being used in all cases. We really can’t just say, “oh well, editors should know better.” While it’s true ESLint will be a little weird in certain cases, I stand by my statement that I think we need to be more conservative with the auto fixes we do, especially in cases like this where we can unintentionally change logic.

nzakas on Jan 22, 2017

This highlights some of the concerns I’ve mentioned around us doing too much auto fixing. When we first started, the intent was to only do white space fixes, and we’ve kept getting more aggressive with other types of fixes too. I think this is a case where we need to start pulling back and being a lot more conservative about applying fixes.

For this particular rule, I think it would be fine to consider a comment as a disqualifying statement, although I also think it would be fine to just remove autofixing from the rule entirely.

Partial auto fixes is a level of complexity I’d like to avoid, as it will make life harder in a lot of ways (case in point: editors would have to choose and likely would just fix everything, which leaves us in the same boat).

nzakas on Jan 21, 2017

I understand…It’s difficult. but…

my writing sequence as follows… write some condition check and TODO comment.

function foo(key) {
  var value = map[key];
  if(!value){
    return;
  }
  // TODO something
}

and write other code, and save… go back to TODO comment.

I need ‘return;’ when writting a code. so i changed ‘warn’ but removed by ‘fix’… so i have to change ‘off’…

by the way. this rule cannot fix source. because fixed source “if(!value){}” does not need.(no-empty)

function foo(key) {
  var value = map[key];
  if(!value){
  }
  // TODO something
}

uk-taniyama on Jan 21, 2017