Disable the arrow-body-style rule

[leroykorterink]

There is a proposal to disable the arrow-body-style rule.

this is just a style preference with no real impact in the result. I prefer to use the arrow function syntax when the body is a single expression, but I don't think it's worth enforcing it.
- @edgardz

Please see the documentation

[leroykorterink]

We should not disable the arrow-body-style rule. The rule is important because it enforces a consistent coding style for arrow functions. It helps improve code readability and maintainability by providing a clear and concise syntax for arrow functions. prettier won't remove unnecessary braces, most problems reported by this rule are auto-fixable and will take little effort to resolve.

Incorrect code

let foo = () => {
    return 0;
};

let bar = () => {
    return {
       bar: {
            foo: 1,
            bar: 2,
        }
    };
};

Correct code

let foo1 = () => 0;

let foo2 = () => ({
    bar: {
        foo: 1,
        bar: 2,
    }
});

let foo3 = (retv, name) => {
    retv[name] = true;
    return retv;
};

let foo4 = () => { bar(); };

let foo5 = () => {};

[ThaNarie]

this is just a style preference with no real impact in the result.

Those are the prefect candidates to have fixed by prettier, or eslint if prettier doesn't do it (yet).

I prefer to use the arrow function syntax when the body is a single expression,

If you and someone else prefer different things, then the codebase can become inconsistent.
I've also seen it happen that people change existing / each others's code because they prefer it one way or another, sometimes going back and forth.

---

Additionally, most editors (VSCode and Webstorm at least) have a quick fix that can wrap or unwrap the braces/return statement in case you quickly need to add a console log or something.

[edgardz]

Sometimes, you end up with harder-to-read code because of this rule.
Other times you just want to add a comment that clearly refers to the internals of the function, like:

chunk.replace(/(\s{1,5}$)|\s/gu, (_, $1) => {
  // keep the last space of the chunk, replace the others
  return $1 || ' '
})

Again, I like the rule, just don't think it should be enforced.

[ThaNarie]

For completeness, this will be auto-fixed to:

chunk.replaceAll(
  /(\s{1,5}$)|\s/gu,
  (_, $1) =>
    // keep the last space of the chunk, replace the others
    $1 || ' '
);

Which I personally still find perfectly readable.

[edgardz]

Another example I came up while writing on other thread:

This is considered wrong:

const closestChildIndex = children.reduce((previous, current, index) => {
  return Math.abs(current.offsetLeft + x) < Math.abs(children[previous].offsetLeft + x) ? index : previous
}, 0)

becomes this after formatting to comply to the rule:

const closestChildIndex = children.reduce(
  (previous, current, index) =>
    Math.abs(current.offsetLeft + x) <
    Math.abs(children[previous].offsetLeft + x)
      ? index
      : previous,
  0
)

[ThaNarie]

To be fair, when ONLY running prettier, you'd already start with:

const closestChildIndex = children.reduce((previous, current, index) => {
  return Math.abs(current.offsetLeft + x) <
    Math.abs(children[previous].offsetLeft + x)
    ? index
    : previous;
}, 0);

which then gets replaced by this rule to:

const closestChildIndex = children.reduce(
  (previous, current, index) =>
    Math.abs(current.offsetLeft + x) <
    Math.abs(children[previous].offsetLeft + x)
      ? index
      : previous,
  0
)

I guess the only "confusing" thing here, is that the , 0 isn't clearly outside the function body, so after the closing }, but otherwise they are pretty similar.