Error expected parentheses around arrow function argument arrow parens



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.

Читайте также:  Exception testing in software testing

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:

Читайте также:  Exception std bad alloc

«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:

  1. The version of ESLint you are using (run eslint -v )
  2. What you did (the source code and ESLint configuration)
  3. The actual ESLint output complete with numbers
  4. 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:

Читайте также:  Error freebsd route add command failed external program exited with error status 1

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.

Источник

Оцените статью
toolgir.ru
Adblock
detector