Update configuration.js

[mordamax]

Fix #6

[joao-paulo-parity]

I prefer it as "always" because I don't like the special syntax needed for blockless arrow functions. For very simple functions (single line) it looks somewhat fine but in other cases it makes the code looks inconsistent with the rest of the code that doesn't need special syntax and special semantics (implicit return).

From my experience those are their downsides

1. It's harder to debug functions without a block. e.g. If I have

foo.bar((baz) => {
  // code
})

I can simply

foo.bar((baz) => {
+  debugger // or console.log(...)
  // code
})

But if I have foo.bar((baz) => foo(baz)) it's more difficult to write a debugger/print statement - I'd have to do a mini-refactor of the code for that and revert it after. Using "bodyless" style makes it more cumbersome to quickly debug something and I don't think the "readabilty" gains are worth it.

2. Object literal looks less readable as showcased by how getTypescriptOverride changed because the { for opening the object is glued to the (.

So in my opinion "bodyless" only looks good in the .foo(val => short) expressions and terrible/inconsistent everywhere else, hence why it's as "always" right now.

I'll ask for a third opinion here from @mutantcornholio.

If we're going with as-needed I'll vote for going with { "requireReturnForObjectLiteral": true } (https://eslint.org/docs/rules/arrow-body-style#requirereturnforobjectliteral)

[mordamax]

I really miss to see these nice shorthands... aren't they worth adding few curly braces sometimes to debug? ))

[mordamax]

isn't it too verbose for such straighforward operations?

[mutantcornholio]

And I would actually prefer as-needed without requireReturnForObjectLiteral :D
It's a matter of habit and aesthetics, so I sure can live with other options

As all options have their pros and cons, should we pick the option with least changes to make?

[mutantcornholio]

Or wait, that's actually what @mordamax originally suggested, right?

Do we want to vote on requireReturnForObjectLiteral separately?

[joao-paulo-parity]

Am I right, that { "requireReturnForObjectLiteral": true } will still end up with something like this ?

@mordamax No because that rule only matters for returning object literals. Please check out the example in https://eslint.org/docs/rules/arrow-body-style#requirereturnforobjectliteral.

[mutantcornholio]

but no one is opposing against it

I do oppose against it.
Not strongly, as it's all codestyle and I could live with any configuration, but that's what we're discussing, right?
For me, requireReturnForObjectLiteral doesn't bring much to the table and forbids me to write the code how I like to write it.

@mordamax I left an example right above your comment. This is a flag that forbids to quickly return object from an arrow function, and would require a function body with a return.

[mordamax]

as I understand only if you return an object.
in case of expression like this (attached) it works as short-hand

[mutantcornholio]

Exactly. And I'd like to be able to return an object with a simpler syntax.

[mordamax]

Even though ideally i'd like requireReturnForObjectLiteral: false, I think as-needed already good improvement.
So if @joao-paulo-parity is strongly against it, while you're not strongly against it (same as me), I'd end up with requireReturnForObjectLiteral: true as a decent compromise for majority of use-cases of short-hand expressions.
If you agree, lets merge, otherwise, i'd propose to keep "never", as it was before, since it's the way how many projects already have been built

[joao-paulo-parity]

Changing my review's status from "requested changed" to "comment" to unblock the merge

Didn't work