Create except-object exception to arrow-body-style rule, enforcing explicit return of object literals from arrow functions.

[duncanbeevers]

The arrow-body-style rule enforces braceless function bodies when the function consists of a single return statement.

When constructing arrow functions which return object literals, the return value must be wrapped in parentheses to force its evaluation as an expression.

The proposed new option enforces a block body with an explicit return value for object literals returned from arrow functions.

Valid

var foo = () => { return; { bar: 0 }; };
var foo = () => 0;

Invalid

var foo = () => ({ bar: 0 });

[nzakas]

I'm not sure I'm understanding this correctly. You're proposing to add an option that requires the use of return if you want to return an object literal, is that correct?

[duncanbeevers]

Yes, exactly.

[BYK]

I think this is a fair request.

[nzakas]

@BYK are you championing this change?

My feedback:

• It's unclear to me if this is really a third option, equal to "always" and "as-needed". It seems like it could actually apply in addition to " as-needed". This needs some discussion.
• I don't think "except-object" is a good name. We generally try to stay away from using "except" because it's unclear. We tend to use "allow", " skip", etc., words that have clearer meaning.

[duncanbeevers]

Yes, the naming for this is a little awkward. "except-object" is a refinement of "as-needed", not a distinct third option.

Conceivably, this could live as its own eslint plugin (parenthesized-object-literals or something) but in practice arrow functions are the only place I've seen them appear, as well as the only place I want to enforce this.

[BYK]

Don't want to over commit so holding on for championing for now in case someone else can do it. If we can't find anyone else in a week I'll take it on. Sounds good?

Also agree that this needs more discussion and consideration before moving forward with the code.

[BYK]

@eslint/eslint-team - anyone else interested in this rule? Either championing or contributing to the discussion?

[mikesherov]

I vote that this should be a third option as its not truly needed.

[nzakas]

@BYK it's been a week, are you championing? :)

Also, agree with @mikesherov that this would be a third option.

[BYK]

@nzakas - okay you got me, championing.

[nzakas]

Okay, we just need three 👍s to move forward.

I'll give you one: 👍

[mikesherov]

👍

[alberto]

👍 @BYK I could also take this

[BYK]

@alberto I'm just getting back to speed so if you have free time go for it. Otherwise I'll get to this eventually :)

[alberto]

Cool

[alberto]

I added the needs bikeshedding because I think we still need to settle on the option name (sorry for not being explicit). Is that tag appropriate for this?

[alberto]

I'm having trouble finding a name for a standalone option :( Any ideas?

[duncanbeevers]

What do you think of a third argument which refines the existing "as-needed" setting?

"arrow-body-style": [2, "as-needed", "skip-object-literal"]

[nzakas]

We could do allowObjectLiteralBody with a default value of true and let people switch to false to force the use of curlies.

@BYK as champion, can you drive this discussion to a conclusion?

[duncanbeevers]

@BYK @alberto

What do you think of using an extension similar to the avoidQuotes option used for the object-shorthand rule?

"arrow-body-style": [2, "as-needed", { avoidParens: true }]

[nzakas]

I don't think avoidParens is specific enough. I would expect that option to also flag a => (B)

[BYK]

I'm +1 to allowObjectLiteralBody: true suggestion for now. If we get 2 more 👍s I'd say we go with that.

[alberto]

I'm sorry but I'm still not sure if you intend that as a new option or as a refinement for as-needed. @nzakas @BYK

[platinumazure]

Added "needs bikeshedding" label since we're still hashing a few things out.

[BYK]

I think this should be an option for as-needed mode.

[alberto]

Thanks, that makes more sense to me. I was bit confused by the previous conversation. Should we use requireForObjectLiteral instead?. My concern is allow doesn't convey not using braces is discouraged in that case.

[BYK]

@alberto - I'm not really sure actually. requireForObjectLiteral implies "require 'arrow function body' for object literal" which is an option to make the rule more strict. AFAIK we tend to have options that relax the original rule and allowObjectLiteralBody fits into that.

What do you think?

[alberto]

Ok, I think I see your point.

[ilyavolodin]

It looks like there are two PRs for this issue: #5934 and #6216 Should we close one of them?

[BYK]

I'd close #5934 since it was created before the issue was accepted (hence before all these discussions). That said since @duncanbeevers is a new collaborator, there's a case to get his first patch in too. What do you think @ilyavolodin and @alberto.

[mikesherov]

I think we should favor new contributions here.

[ilyavolodin]

Agree with @mikesherov @alberto Would you mind guiding @duncanbeevers with the necessary updates to his PR?

[alberto]

oh, sorry, I didn't see that PR since it wasn't linked to the issue.

@duncanbeevers are you still interested in implementing this?

[duncanbeevers]

I appreciate being favored for contribution, but I @alberto's #6216 is already done and ready for inclusion. I can't imagine implementing it any differently than they did, so I'd prefer #6216 to #5934

[BYK]

@duncanbeevers - thanks! Alright then, I closed #5934 and I think #6216 is ready to merge.

[alberto]

ok, @duncanbeevers. Thanks for your contribution anyway!