Skip to content
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

Merged
merged 1 commit into from Jun 10, 2016

Conversation

alberto
Copy link
Member

@alberto alberto commented May 18, 2016

No description provided.

@eslintbot
Copy link

LGTM

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @vitorbal, @gyandeeps and @pedrottimark to be potential reviewers

@eslintbot
Copy link

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;
Copy link
Member

@BYK BYK May 20, 2016

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?

Copy link
Member Author

@alberto alberto May 20, 2016

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.

@nzakas
Copy link
Member

nzakas commented May 23, 2016

@alberto can you rebase when you get a second?

@eslintbot
Copy link

LGTM

@alberto
Copy link
Member Author

alberto commented May 25, 2016

@BYK @nzakas PR updated and rebased

@BYK
Copy link
Member

BYK commented May 25, 2016

Still a bit confused about what enforceObjectLiteralBody means because I first assumed it would enforce an arrow function body so when it was set to true it would require () => { return {a:1}} and complain when it saw () => ({a: 1}).

Thoughts?

@alberto
Copy link
Member Author

alberto commented May 26, 2016

Really, did I get it wrong again 😵 ? So you now expected it to be false by default and the option to make the rule stricter?

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".

@BYK
Copy link
Member

BYK commented May 26, 2016

@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 :(

@platinumazure
Copy link
Member

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!

@alberto
Copy link
Member Author

alberto commented May 26, 2016

yeah, no problem @BYK

@nzakas
Copy link
Member

nzakas commented May 26, 2016

@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 avoidObjectLiteralBodyParens?

@BYK
Copy link
Member

BYK commented May 26, 2016

enforceFunctionBodyForObjectLiterals?

@alberto
Copy link
Member Author

alberto commented May 26, 2016

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 arrow-body-style omits the part about the block:
Maybe enforceBlockBodyForObjectliterals or avoidConciseBodyForObjetLiteral?

@BYK
Copy link
Member

BYK commented May 26, 2016

How about noBodyExpressionForObjectLiteral?

@alberto
Copy link
Member Author

alberto commented May 27, 2016

@eslint/eslint-team we could use some help here picking an good name :)

@btmills
Copy link
Member

btmills commented May 27, 2016

returnObjects?

@mysticatea
Copy link
Member

I thought:

"arrow-body-style": ["error", "as-needed", {"returnObjectLiteral": "needed"}]

@BYK
Copy link
Member

BYK commented Jun 1, 2016

@alberto what do you think about @mysticatea's suggestion?

@alberto
Copy link
Member Author

alberto commented Jun 1, 2016

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 neededForObjectLiteral or needsReturnForObjectLiteral?

@BYK
Copy link
Member

BYK commented Jun 1, 2016

@alberto boolean suggestion: requireReturnForObjectLiteral

@mikesherov
Copy link
Contributor

👍 to requireReturnForObjectLiteral

@alberto
Copy link
Member Author

alberto commented Jun 1, 2016

Yes :) 👍

@eslintbot
Copy link

LGTM

@alberto alberto added the do not merge This pull request should not be merged yet label Jun 4, 2016
@alberto
Copy link
Member Author

alberto commented Jun 4, 2016

Labelling as do not merge since it was decided to go with #5934 instead.

@nzakas
Copy link
Member

nzakas commented Jun 6, 2016

@alberto where was that decided?

@alberto
Copy link
Member Author

alberto commented Jun 6, 2016

@nzakas in the original issue, to prioritize new contributions

@nzakas
Copy link
Member

nzakas commented Jun 6, 2016

@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).

@BYK BYK removed the do not merge This pull request should not be merged yet label Jun 9, 2016

* `"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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

finer-grained?

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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 ;)

@BYK
Copy link
Member

BYK commented Jun 9, 2016

All inline comments are nitpicks and optional. LGTM overall. Thanks for baring with me @alberto! :)

@eslintbot
Copy link

LGTM

@BYK
Copy link
Member

BYK commented Jun 10, 2016

@nzakas or @ilyavolodin can we merge this? :)

@ilyavolodin ilyavolodin merged commit 9bfbc64 into master Jun 10, 2016
@alberto alberto deleted the issue5936 branch June 13, 2016 19:48
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 6, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Feb 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet