prefer-arrow-callback fix conflicting with prettier fix

Edit by @lydell: TL;DR We recommend turning off these rules for the time being:

{
  "rules": {
    "arrow-body-style": "off",
    "prefer-arrow-callback": "off"
  }
}

---

What version of eslint are you using? v4.9.0

What version of prettier are you using? v1.7.4

What version of eslint-plugin-prettier are you using? v2.3.1

Please paste any applicable config files that you’re using (e.g. .prettierrc or .eslintrc files) https://github.com/ismail-syed/prettier-eslint-config-invalid-code

What source code are you linting?

function foo() {
  return isTrue && [0,1,2].map(function(num) {
    return num * 2;
  });
}

What did you expect to happen? The code above should be formatted as per prettiers config and also should adhere to that prefer-arrow-callback fix

What actually happened? Invalid code was generated, closing parenthesis is missing on the return statement.

function foo() {
  return (
    isTrue &&
    [0, 1, 2].map((num) => {
    return num * 2;
  });
}

Is the underlying issue from the prefer-arrow-callback fixer or the prettier plugin fixer?

[ljharb]

Not necessarily - it could just be sure to specifically replace entire arrow functions at once, no?

[BPScott]

What’s the differences in user experience and why do you consider them to be worse?

Thanks for calling me out on that, I knew I was being lazy with that handwaving 😃

Currently this plugin does the following:

• Grab the entire contents of a JS file and push it into prettier
• Compare the original input with prettier’s output. For each block of differences then mark them as changes in eslint.

This means that if you have a file like:

const a = 0;
const b=0;
const c = 0;
const d=0;
const e = 0;

it will report changes (adding the spacing around the equals) on lines 2 and 4.

const a = 0;
-const b=0;
+const b = 0;
const c = 0;
-const d=0;
+const d = 0;
const e = 0;

This “find the smallest block of changes” logic gives a nice DX experience as it means the smallest change a user needs to make is shown.

---

The naive shotgun approach that would solve the problem, but give a crappy DX is to not try and split out changes into atomic parts, and instead batch all the changes into one big one. In this case the suggested fix for the above code would be:

const a = 0;
-const b=0;
-const c = 0;
-const d=0;
+const b = 0;
+const c = 0;
+const d = 0;
const e = 0;

Note that the c line is caught up in the change too despite it not requiring any modifications. This seems kinda reasonable in a small example but what if you had a 100 line file and the first change requested by prettier was on line 2 and the last change requested was on like 70. This algorithm would say that lines 2-70 would all need to change, despite most of that content being identical. Making two mistakes and large swaths of your file getting a red wavy line of whoops underneath it is a bad experience as it makes it very hard to tell what actually got changed.

While this approach is simple to implement the potential for making hard to understand suggestions that make it untenable IMO.

---

The 3rd approach is @ljharb’s - a diff mechanism that understands JS and can block changes within a function into a single change. This would solve the problem but a very quick search came up with no drop-in solution available at the moment, and my gut thinks implementing a diffing algorithm that understands JS logic would be complex and much slower than the current algorithm.

If there’s a way that this can happen without adding too much complexity to our codebase and doesn’t have a major performance impact then I’d be interested in reviewing a PR but I don’t have much interest in attempting to solve this personally as my gut thinks it’s going to be a lot of effort and a lot of complexity for worse overall performance for a problem that only crops up occasionally. Happy to be proved wrong though 😃