New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update: Option for object literals in arrow-body-style
(fixes #5936)
#6216
Conversation
LGTM |
By analyzing the blame information on this pull request, we identified @vitorbal, @gyandeeps and @pedrottimark to be potential reviewers |
LGTM |
}, | ||
|
||
create: function(context) { | ||
var always = context.options[0] === "always"; | ||
var asNeeded = !context.options[0] || context.options[0] === "as-needed"; | ||
var allowObjectLiteralBody = context.options[1] && context.options[1].allowObjectLiteralBody === true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean context.options[1].allowObjectLiteralBody !== false
since the default should be true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got the meaning backwards. I'll change it so enforceObjectLiteralBody
is true
by default and you allow explicit return with false
.
@alberto can you rebase when you get a second? |
LGTM |
Still a bit confused about what Thoughts? |
Really, did I get it wrong again 😵 ? So you now expected it to be FWIW, In both cases there is an object literal, and there is a body. What this rule is really enforcing is the presence of the block in the body. So I understood it as "enforce object literal as body". |
@alberto I don't think you got it wrong. It is just very hard to get the right name. That said I put the blame mostly on myself for making you change it again and again. If you're okay let's pause and try to come up with a less ambiguous name before wasting your time. What do you think? And I am sorry for this :( |
For what it's worth, I don't think we should necessarily design our rules to be as strict as possible and assume that options should relax the rules. I think we should design so that the default options correspond to the most common case, and then options merely represent variations on that case. Just my two cents. Good luck on this one! |
yeah, no problem @BYK |
@platinumazure that only works when creating a new rule. When modifying an existing rule, we need to maintain backwards compatibility, and that often means introducing options that turn off parts of the rule. What about |
|
I don't think "function body" is the most appropriate. Blockless arrow functions also have bodies. I think the problem comes from the fact that |
How about |
@eslint/eslint-team we could use some help here picking an good name :) |
|
I thought:
|
@alberto what do you think about @mysticatea's suggestion? |
I'm OKish. We tend to use boolean properties for this things. Not that the schema validation wouldn't catch typos but... Would you guys prefer that over something like |
@alberto boolean suggestion: |
👍 to |
Yes :) 👍 |
LGTM |
Labelling as |
@alberto where was that decided? |
@nzakas in the original issue, to prioritize new contributions |
@alberto that's fine, but it would be better to link to the comment so people who aren't hopping back and forth between the issue can still follow what's going on (me, for instance). |
|
||
* `"always"` enforces braces around the function body | ||
* `"as-needed"` enforces no braces where they can be omitted (default) | ||
|
||
### "always" | ||
The second one is an object for more fine-grained configuration when the first option is `"as-needed"`. Currently, the only available option is `requireReturnForObjectLiteral`, a boolean property. It's `false` by default. If set to `true`, it requires braces and an explicit return for object literals. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
finer-grained?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it requires braces and an explicit return for object literals.
it requires braces for the function body and an explicit return
when the return value is just an object literal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BYK I am not a native english speaker, so I'm not completely sure what's better, but we use the expression "more fine-grained" in 3 other rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was just a suggestion so okay to leave it that way ;)
All inline comments are nitpicks and optional. LGTM overall. Thanks for baring with me @alberto! :) |
LGTM |
@nzakas or @ilyavolodin can we merge this? :) |
No description provided.