Stage 4 syntaxes in core rules

[mysticatea]

acorn, the base of espree, has supported async/await and trailing function commas: Acorn 4.0.0
espree is going to support those, coming soon: eslint/espree#287

Then, I'm starting to modify core rules to support those.
In my head, the following rules need some tweaks.

• 1st
  • Upgrade: espree to 3.2.0, remove tests with SyntaxErrors (fixes #7169) #7170 no-dupe-args ... Duplicate names in non-simple parameters are illegal syntax. We need to fix our tests since Acorn has enhanced the check. (4 tests are failing now with Acorn 4.0.0)
  • Upgrade: espree to 3.2.0, remove tests with SyntaxErrors (fixes #7169) #7170 no-redeclare ... Duplicate names in exports are illegal syntax. We need to fix our tests since Acorn has enhanced the check. (2 tests are failing now with Acorn 4.0.0)
• 2nd
  • Update: Ensure arrow-parens handles async arrow functions correctly #7176 arrow-parens ... It has false positive/negative on async functions.
  • Update: keyword-spacing supports async/await (refs #7101) #7179 keyword-spacing ... It has false positive/negative on async functions.
  • Update: no-extra-parens supports async/await (refs #7101) #7178 no-extra-parens ... It should handle await expressions also by default.
  • Fix: Handle await expressions correctly in no-unused-expressions #7175 no-unused-expressions ... It should handle await expressions also by default.
  • Fix: Handle async functions correctly in prefer-arrow-callback fixer #7173 prefer-arrow-callback ... It has wrong autofix on async functions.
  • Update: space-before-function-paren supports async/await (refs #7101) #7180 space-before-function-paren ... It should handle async arrow functions (as anonymous function?). async(a) => a.
  • Update: Allow space-unary-ops to handle await expressions #7174 space-unary-ops ... It should handle await expressions. It has handled yield expressions already.
• 3rd
  • Fix: Don't report async/generator callbacks in array-callback-return #7172 array-callback-return ... I think should not warn async functions as callbacks. Promise.all(list.map(async x => { await doSomething(x) }) is legal usage.
  • Update: comma-dangle supports trailing function commas (refs #7101) #7181 comma-dangle ... It should check functions also by opt-in.
  • Chore: add tests for generator-star-spacing and async (refs #7101) #7182 generator-star-spacing ... To make sure, it needs tests for async functions.

Changelog:

• space-before-function-paren was added.
• space-unary-ops was added.
• Sorted by priority.
• generator-star-spacing was added.

[hzoo]

maybe generator-star-spacing? https://github.com/babel/eslint-plugin-babel has an override for that

[mysticatea]

generator-star-spacing should work for async functions since node.generator of async functions is false.

[hzoo]

Oh right, it was probably one of the rules you already mentioned then. Still need to fix it in babel-eslint. My mistake

[mysticatea]

Hmm. I have a question:

async () => 0
//   │
//   └ Should this space be warned by which rule?
//
// 1. keyword-spacing
// 2. space-before-function-paren
//
// By the way,
(function () {})
//       │
//       └ This space is warned by space-before-function-paren

I guess space-before-function-paren is it.

[platinumazure]

@mysticatea Is async function foo() {} valid syntax? If so I would rather have keyword-spacing cover both cases. But I can see arguments for either way!

[mysticatea]

Yes, async function foo() {} is valid. But we cannot remove the space between async and function, so keyword-spacing rule ignores it.

[kaicataldo]

I think this should be warned by keyword-spacing. Given the intent of space-before-function-paren, my preference would be to maintain not checking ArrowFunctionExpressions in that rule. To me, it makes more sense for the checks to not care about whether the token following the async keyword is a FunctionDeclaration, FunctionExpression, or ArrowFunctionExpression, but rather for the checks to focus on spacing around the keyword itself. It also avoids having to configure in two places would arguably should be one configuration.

For context, in my ideal world, I think space-before-function-paren would actually only warn on named functions, leaving anonymous function spacing to keyword-spacing.

[mysticatea]

For context, in my ideal world, I think space-before-function-paren would actually only warn on named functions, leaving anonymous function spacing to keyword-spacing.

I agree! In the ideal world, definitely keyword-spacing should warn the space.
But in this world, I have the concern that the priority of spacing rules is confusing: a mix of keyword-spacing > space-before-function-paren or keyword-spacing < space-before-function-paren.

	keyword-spacing	space-before-function-paren
Pros	don't need to modify space-before-function-paren.	the priority of spacing rules is consistent: keyword-spacing < space-before-function-paren
Cons	keyword-spacing > space-before-function-paren in arrow but keyword-spacing < space-before-function-paren in others.	needs new option asyncArrow for space-before-function-paren

[not-an-aardvark]

It looks like a new version of espree just came out with acorn 4.0.0, so our tests are now failing on master (example).

[ilyavolodin]

Umm.. That's not good. That shouldn't be happening, since we haven't enabled ES2018 anywhere yet. I'll open a new issue for this.

[not-an-aardvark]

I've been working on a few of the issues on this list; see #7172, #7173, #7174, #7175, #7176.

[mysticatea]

Oh, I have been late for the party. Thank you, @not-an-aardvark .
(often releases are done in midnight in my timezone.)

[mysticatea]

Filled all items with PRs.

[Gawdl3y]

I created #7307, which is a problem with the valid-jsdoc rule on async functions that I don't believe is mentioned here.