no-confusing-arrow flags conditionals inside parentheses.

[dtinth]

ESLint Version: 2.1.0

This is a pattern I use frequently in JavaScript code:

const renderItem = item => (isSeparator(item)
  ? React.createElement(Separator)
  : React.createElement(MenuItem, item)
)

Note that the conditionals are inside parentheses. In this case, the meaning is not ambiguous. You can’t interpret a => (1 ? 2 : 3) as (a >= 1) ? 2 : 3.

Test Case

/* eslint no-confusing-arrow: 2 */
var x = a => (1 ? 2 : 3)

Expected Result

No lint errors.

Actual Result

Arrow function used ambiguously with a conditional expression. (no-confusing-arrow)

[nzakas]

Confirmed. Do you want to submit a pull request for this?

[alberto]

What about this?

var a = 2;
var x = a >= (true ? 2 : 3);

[alecmev]

This bug is even worse with arrow-body-style set to as-needed. It essentially makes it impossible to express a => 1 ? 2 : 3 without ESLint showing an error.

[gilbarbara]

Hey! I just ran into this problem..
With no-confusing-arrow and arrow-body-style rules on, I can't seem to pass the validations.

input.replace(tags, ($0, $1) => (allowed.indexOf(`<${$1.toLowerCase()}>`) > -1 ? $0 : ''));

triggers no-confusing-arrow

input.replace(tags, ($0, $1) => { return allowed.indexOf(`<${$1.toLowerCase()}>`) > -1 ? $0 : ''; });

triggers arrow-body-style

I think that allowng parentheses around the expression will be great.

[dtinth]

Would love to work on it, but have been quite busy, so I am not sure whether I’ll have time to do it.

@nzakas @jeremejevs @gilbarbara What do you think about @alberto’s case?

Does var x = a => (true ? 2 : 3) look confusing?

For me, I think it’s pretty clear that it’s a function that returns some value, because I get used to seeing this: => (.

[platinumazure]

I think an arrow shouldn't be considered "confusing" (as in, could be confused with >=) if there is a parenthesis token in between. Or at least, there should be an option for it. (I was trying to think if >= ( was always non-parseable, but unfortunately it does parse in many cases, so it should probably be an option for the user.)

[alecmev]

@alberto Your example isn't limited to ternary, though. Any (every?) "concise body" arrow function can be confusing in one way or another, no?

var a = 2;
var x = a >= (true ? 2 : 3);
var y = a >= (b || a);
var z = a >= Math.sin(a);

Isn't this static typing jurisdiction?

[alberto]

@jeremejevs Every arrow function with a concise body and taking exactly one argument, yes. I think that's (or should be) the purpose of the rule.

[BYK]

Working on this, pretty close. Added a allowParens option defaulting to false to keep the old behavior as default.

[shinzui]

Is allowParens set to true supposed to work with no-extra-parens. It's now triggering "Gratuitous parentheses around expression. (no-extra-parens)".