Arrow Functions incorrectly trigger errors on func-names & space-before-blocks about babel-eslint

[sebmck]

There's only so much that can be done. Arrow functions that have expression bodies need to be transformed to have a body or else #20 happens.

[nzakas]

Can you try with the default ESLint parser to see if you get the same issues?

[keithamus]

ESLint parser does not have the same issue with func-names; espree parses Arrow functions as type: "ArrowFunctionExpression"^{[1], [2]} which is ignored by the func-names rule^[3]

Interestingly, the Mozilla Parser API indicates that it should be neither "FunctionExpression" nor "ArrowFunctionExpression" - but actually "ArrowExpression"^[4].

Esprima also parses arrows as "ArrowFunctionExpression"^[5]

[keithamus]

As for space-before-blocks. Esprima counts the inline arrow function as an expression, e.g. () => x*x; is a BinaryExpression, but does count it as a block when presented with curlies, (e.g. () => { return x*x; }).

This behaviour seems like the correct way. Espree also follows this same pattern (I cannot link as it does not have an online repl, but I did verify this).

[sebmck]

@keithamus Yes, this is because babel-eslint was designed for eslint 0.15.x before it had ES6 support so it had to convert nodes that ESLint didn't understand to ones that it did. I'm currently tied up in work on the Babel core but I'm more than welcome to a pull request to update all the nodes to 0.16.x.

[keithamus]

Totally fine 😄 I just thought I'd add my findings, I doubt I'll be able to find the time to fix this.

Right now I'm using eslint 0.16 with the ES6 features turned on, which seems to be more reliable than babel-eslint.

[sebmck]

Should be fixed if you upgrade babel-eslint to 2.0.0 and eslint to 0.16.x, thanks!