arrow-parens
Require parentheses around arrow function arguments
Some problems reported by this rule are automatically fixable by the —fix command line option
Arrow functions can omit parentheses when they have exactly one parameter. In all other cases the parameter(s) must be wrapped in parentheses. This rule enforces the consistent use of parentheses in arrow functions.
Rule Details
This rule enforces parentheses around arrow function parameters regardless of arity. For example:
Following this style will help you find arrow functions ( => ) which may be mistakenly included in a condition when a comparison such as >= was the intent.
The rule can also be configured to discourage the use of parens when they are not required:
Options
This rule has a string option and an object one.
String options are:
- «always» (default) requires parens around arguments in all cases.
- «as-needed» enforces no parens where they can be omitted.
Object properties for variants of the «as-needed» option:
- «requireForBlockBody»: true modifies the as-needed rule in order to require parens if the function body is in an instructions block (surrounded by braces).
always
Examples of incorrect code for this rule with the default «always» option:
Examples of correct code for this rule with the default «always» option:
If Statements
One of the benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:
The contents of the if statement is an arrow function, not a comparison.
If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.
The following is another example of this behavior:
f is an arrow function which takes a as an argument and returns the result of b ? c: d .
This should be rewritten like so:
as-needed
Examples of incorrect code for this rule with the «as-needed» option:
Examples of correct code for this rule with the «as-needed» option:
requireForBlockBody
Examples of incorrect code for the < "requireForBlockBody": true >option:
Examples of correct code for the < "requireForBlockBody": true >option:
Version
This rule was introduced in ESLint v1.0.0-rc-1.
async (t) => < >— Expected parentheses around arrow function argument. #416
Comments
azhang commented Feb 10, 2016
I’m getting Expected parentheses around arrow function argument. errors with my async arrow functions. Perhaps this is more of a eslint issue than a standardjs issue?
The text was updated successfully, but these errors were encountered:
feross commented Feb 10, 2016
There’s already another discussion about this here: #414
azhang commented Feb 10, 2016
Oh, actually I don’t get that issue. I only get errors on async arrow functions.
Sent from my iPhone
On Feb 10, 2016, at 1:43 PM, Feross Aboukhadijeh notifications@github.com wrote:
—
Reply to this email directly or view it on GitHub.
feross commented Feb 10, 2016
Oh didn’t realize this was only for async arrow functions.
dhax commented Feb 11, 2016
having the same issue with async arrow function with basic setup:
cesarandreu commented Feb 11, 2016
Having the same issue. This prevents us from upgrading to standard v6.
azhang commented Feb 11, 2016
I made an issue in the babel-eslint repo as well: babel/babel-eslint#252
benjyhirsch commented Feb 13, 2016
This is a known issue with some of the rules in babel-eslint, hence https://github.com/babel/eslint-plugin-babel
From the description:
An eslint plugin companion to babel-eslint. babel-eslint does a great job at adapting eslint for use with Babel, but it can’t change the built in rules to support experimental features. eslint-plugin-babel re-implements problematic rules so they do not give false positives or negatives.
One of the rules is:
babel/arrow-parens : Handles async functions correctly
cesarandreu commented Feb 18, 2016
This issue keeps us from upgrading, we’re using async arrow functions a lot. Even if we add eslint-plugin-babel , according to #404 it seems v7 is gonna be removing «rules», so we’d have no way of replacing the eslint rule with the plugin rule?
Hmm, maybe making a standard-babel would make sense?
feross commented Feb 20, 2016
@cesarandreu That’s certainly one option, but I wonder if we shouldn’t just disable/change this rule given the opposition to it in the other issue #414 (comment)
Name already in use
archive-website / docs / 2.0.0 / rules / arrow-parens.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
Copy raw contents
Copy raw contents
Require parens in arrow function arguments (arrow-parens)
Arrow functions can omit parentheses when they have exactly one parameter. In all other cases the parameter(s) must be wrapped in parentheses. This rule enforces the consistent use of parentheses in arrow functions.
This rule enforces parentheses around arrow function parameters regardless of arity. For example:
Following this style will help you find arrow functions ( => ) which may be mistakenly included in a condition when a comparison such as >= was the intent.
The rule can also be configured to discourage the use of parens when they are not required:
The rule takes one option, a string, which could be either «always» or «as-needed» . The default is «always» .
You can set the option in configuration like this:
«arrow-parens»: [2, «always»]
When the rule is set to «always» the following patterns are considered problems:
The following patterns are not considered problems:
One benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:
The contents of the if statement is an arrow function, not a comparison. If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.
The following is another example of this behavior:
f is an arrow function which takes a as an argument and returns the result of b ? c: d .
This should be rewritten like so:
When the rule is set to «as-needed» the following patterns are considered problems:
The following patterns are not considered problems:
This rule was introduced in ESLint 1.0.0-rc-1.
arrow-parens + async arrow function bug #6311
Comments
phaux commented Jun 2, 2016
That causes an error:
Expected parentheses around arrow function argument. at line 1 col 12
ESLint 2.11.1 using Babel-ESLint parser
The text was updated successfully, but these errors were encountered:
eslintbot commented Jun 2, 2016
Hi @phaux, thanks for the issue. It looks like there’s not enough information for us to know how to help you. If you’re reporting a bug, please be sure to include:
- The version of ESLint you are using (run eslint -v )
- What you did (the source code and ESLint configuration)
- The actual ESLint output complete with numbers
- What you expected to happen instead
Requesting a new rule? Please see Proposing a New Rule for instructions.
If it’s something else, please just provide as much additional information as possible. Thanks!
vitorbal commented Jun 2, 2016
Could this be related to #6274 or #6281 ?
I’m guessing this is probably a babel-eslint issue with async and the arrow-parens rule. @hzoo does it ring a bell?
hzoo commented Jun 2, 2016
Yep, I would use https://github.com/babel/eslint-plugin-babel#rules — babel/arrow-parens . It sounds like a «babel-eslint» issue but its just that the rule can’t handle newer syntax so currently we have to actually rewrite it as a separate rule + another if check.
vitorbal commented Jun 2, 2016 •
@hzoo thanks, that was a fast reply 🙂
@phaux Could you try with babel/arrow-parens and let us know if that works out for you?
Closing the issue for now.
phaux commented Jun 6, 2016
I didn’t know about eslint-plugin-babel. I will try it out. Thanks
False-positive of arrow-parens with generic arrow function #344
Comments
mnn commented Jul 23, 2018
error Expected parentheses around arrow function argument having a body with curly braces arrow-parens
which doesn’t seem right. Applying fix results in invalid code:
Workaround is rewrite arrow function to classic function.
The text was updated successfully, but these errors were encountered:
gajus commented Jul 23, 2018
Fix would be welcome.
gajus commented Jul 18, 2019
🎉 This issue has been resolved in version 3.12.0 🎉
The release is available on:
Mr-Wallet commented Jul 16, 2020
Still getting this problem on eslint@6.8.0 and eslint-plugin-flowtype@4.7.0 .
gajus commented Jul 16, 2020
Please raise a PR with a broken test case.
Mr-Wallet commented Jul 21, 2020 •
@gajus Question about writing tests: is the assumption that we always be targeting the latest version of flow, and changes to the Flow API are supposed to be handled in future PRs? I don’t see any way to target specific versions of flow.
After 90 minutes, I’m totally at a loss of how to reproduce the error in the tests. I’ve ruled out an interaction with other plugins in my own project, and I’ve copy-pasted a few examples that fail in my project and it doesn’t show an error in the tests. The issue only comes up when defining functions that use Generics, and usually only when those functions are defined as arguments to other functions. Using the function keyword instead of arrow functions is a reasonable work-around (we don’t use this very much in our code base).
I’m prepared to leave this for now and move on to other things. But if you happen have any advice for why the tests might have different results than an actual project, I would be eager to try some more experiments to try and nail down why this is happening.
gajus commented Jul 22, 2020
@gajus Question about writing tests: is the assumption that we always be targeting the latest version of flow, and changes to the Flow API are supposed to be handled in future PRs? I don’t see any way to target specific versions of flow.
That is correct.
I’m prepared to leave this for now and move on to other things. But if you happen have any advice for why the tests might have different results than an actual project, I would be eager to try some more experiments to try and nail down why this is happening.
If you can produce a minimal repository for replicating the issue, that would be enough.