require-await should be disabled for async generators

[mikeal]

What rule do you want to change? require-await

Does this change cause the rule to produce more or fewer warnings? neither

How will the change be implemented? (New option, new default behavior, etc.)? new default behavior

Please provide some example code that this change will affect:

Currently, require-await is enabled for both async functions and async generators.

The problem with this when it comes to generators is that the return value of an async generator contains symbols that a regular generator does not, making it quite different from async functions which are just regular functions that return promises.

Since generators yield rather than return a value, an async generator might yield all the values of another async generator without ever actually needing to use await.

async function * () {
  yield * anotherAsyncGenerator()
}

If you remove the async syntax the generator will fail with the following error:

TypeError: yield* (intermediate value) is not iterable

You can’t actually yield * of an async generator from a regular generator because the generator has to have the right symbols in order to be consumed properly. The VM guards against this and gives us a rather obtuse error.

IMO, it’s probably best to just disable await checking for async generators.

What does the rule currently do for this code? It fails on the required form and will not pass unless disabled.

What will the rule do after it's changed? Not check async generators for await.

Are you willing to submit a pull request to implement this change? Nope.

[dmitryrn]

I'll pick it up

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[kaicataldo]

Reopening this since it seems to have slipped between the cracks.

This makes sense to me, but I’d like to hear what the rest of the team has to say.

[mysticatea]

Sorry for the lack of activity here.

This makes sense to me.

[ljharb]

This makes sense to me too, but a regular async function also might never need to use await for identical reasons, so if this change makes sense, I'd suggest this entire rule be removed in the next major :-)

[mikeal]

@ljharb it’s a bit different.

If you want to require await in all async functions and someone needs to produce an async function that doesn’t have await in it, they can just create a function that returns a promise. This will satisfy whatever need they have in-code and satisfy the linter rule.

For an async generator this isn’t the case because a regular generator that wasn’t created using the syntax won’t have the correct symbols.

[ljharb]

You can manually make a function that returns an object with Symbol.asyncIterator too, but I recognize there's a pretty big difficulty delta between "manually make a promise" and "manually make an asynchronous state machine".

[mikeal]

@ljharb oh totally, i wouldn’t even know how to do that if i hadn’t had to dig through Node.js Core’s async generator support for Streams. most JS developers don’t even know Symbol is a thing ;)

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that accepted issues failing to be implemented after 90 days tend to
never be implemented, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[mdjermanovic]

Reopening since there are open PRs for this issue.