Javascript: [eslint-config-airbnb] Activate rule "require-await"

[marcospgp]

Since this guide is widely used as standard, turning on the rule "require-await", which prevents async functions that do not make use of "await", would be a good idea. Such functions are usually the result of refactoring.

[ljharb]

Absolutely it would not - that rule is horrifically bad, and async functions without await are just fine.

See the comment here: https://github.com/airbnb/javascript/blob/070e6200bb6c70fa31470ed7a6294f2497468b44/packages/eslint-config-airbnb-base/rules/best-practices.js#L317

I argued against eslint core including it as well; it arises from a fundamental misunderstanding of async functions as if they were like generators (they are not) - a generator without yield makes no sense, but an async function without await makes perfect sense.

[marcospgp]

Fair enough. But aren't the cases where you would want async without await edge cases?

[ljharb]

In no way are they edge cases. async function is a syntactic assurance that a function will always return a Promise - it can never throw or return anything else. That's its primary feature.

Being able to use await in it is a side benefit, and unfortunately one that's easily misused as well (unnecessarily making concurrent tasks block on each other, is the most common one). Needing await is the edge case, if anything.

[Izhaki]

async function is a syntactic assurance that a function will always return a Promise - it can never throw or return anything else. That's its primary feature.

That is all good. But I guess this leaves us with the question:

Why would you choose to have a function returning a promise if it does nothing asynchronously?

And also:

Could marking a function as asynchronous when it is in fact synchronous be the source of bugs and extra code complexity?

[ljharb]

@Izhaki For one, you don't need await to do something asynchronously, you could be returning somethingElse() which itself returns a promise; for another, you might be returning a promise solely to ensure a consistent API.

Yes, absolutely - anything could be a source of bugs, this is programming. The priority is to make your code convey your intent clearly, while also being correct. Forcing use of await does not ensure either.

[Izhaki]

I agree.

Recall that an async often requires support up the callee chain, both in terms of further async support and error handling.

I've been working on a promise-heavy code base and more often than not you want async functions to really be part of some async behaviour (which includes what you said - marking function as async because it returns a promise returned by another function, with no await in the body).

I landed on this issue because we had a function marked as async that was no longer async in any way or form, when I left a comment the response was "shouldn't there be an eslint rule for this" (we are using the airbnb config).

I'm not arguing the rule is always good, only that it is not as clear-cut as horrifically bad.

[barberdt]

Just got burned by a non-intentional async usage myself. The beauty of eslint is that rules, even those inherited from a project like this one, can be overridden. That being said, in overriding this rule choice, I found it pretty frustrating to simply see (note: this is a horrible rule that should never be used) without any explanation. Had to hunt down this issue to find some context. Sort of took away from the credibility of the project IMO. Some extra documentation explaining some of this there or maybe even just a link to this issue could help others in the future.

this guide is widely used as standard

I believe this to be entirely true and, as is such, feel like simply stating something is "horrible" and "should never be used" without any context feels like not a great "standard".

[ljharb]

@barberdt if you'd like to improve that comment with a PR, based on consolidating some of the justifications in this thread, that'd be appreciated.