Update: Add never option to arrow-body-style (fixes #6317) #6318
Conversation
|
Thanks for the pull request, @ajhyndman! I took a look to make sure it's ready for merging and found some changes are needed:
Can you please update the pull request to address these? (More information can be found in our pull request guide.) |
|
By analyzing the blame information on this pull request, we identified @vitorbal, @gyandeeps and @alberto to be potential reviewers |
|
Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA). 📝 Please visit http://contribute.jquery.org/CLA/ to sign. After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know. If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check. |
|
LGTM |
Arrow functions that return object literals can look very similar to arrow functions with brace bodies. Some syntactic ambiguity can be avoided by disallowing block-style arrow functions in favour of ES5 function expressions.
**Outcome**
The following patterns are considered problems:
```
/*eslint arrow-body-style: ["error", "never"]*/
/*eslint-env es6*/
let foo = () => {
return 0;
};
let foo = (retv, name) => {
retv[name] = true;
return retv;
};
```
The following patterns are not considered problems:
```
/*eslint arrow-body-style: ["error", "never"]*/
/*eslint-env es6*/
let foo = () => 0;
let foo = () => ({ key: 0 });
```
|
LGTM |
|
thanks @ajhyndman! Marking this as "do not merge" just for now as the proposed enhancement hasn't been accepted yet. |
|
Issue has been accepted so removing "do not merge" |
|
@ajhyndman thanks for this. In order to be merged, can you please update the rule documentation and write some tests for the new option? |
|
Of course, I'll assemble them when I get off work. |
|
LGTM |
4 similar comments
|
LGTM |
|
LGTM |
|
LGTM |
|
LGTM |
|
Sorry about the spam. I tried to keep the documentation fairly consistent with what was already there, but I'm happy to adjust it, if need be. The tests just codify the documentation. |
| This rule can enforce the use of braces around arrow function body. | ||
| Arrow functions have two syntactic forms for their function bodies. They may be defined with a *block* body (denoted by curly braces) `() => { ... }` or with a single expression `() => ...`, whose value is implicitly returned. | ||
|
|
||
| This rule may be used to standardize your usage and thus avoid syntactic ambiguity. |
There was a problem hiding this comment.
I think maybe " This rule can enforce or disallow the use of braces around arrow function body." is a more easily understandable way of saying this.
|
LGTM |
|
I think you're right. There was a bit of redundancy, and we lost the explicit description of the mechanics. I've applied your suggestions. |
|
Thanks, LGTM! |
| The following patterns are not considered problems: | ||
|
|
||
| ```js | ||
| /*eslint arrow-body-style: ["error", "as-needed"]*/ |
There was a problem hiding this comment.
option name should be "never" here
|
Other than the doc typo, LGTM. |
|
LGTM |
|
Whoops, good catch, thanks! |
|
LGTM. Thanks |
eslint-deprecated
bot
added
the
archived due to age
Arrow functions that return object literals can look very similar to arrow functions with brace bodies. Some syntactic ambiguity can be avoided by disallowing block-style arrow functions in favour of ES5 function expressions.
Outcome
The following patterns are considered problems:
The following patterns are not considered problems: