Tools: 💭 [lint] require `await` inside `async` functions

[ematipico]

Upstream rule: https://eslint.org/docs/rules/require-await

Basically I would like to propose a rule where we enforce the use of await if a function is marked with async.

Unfortunately with TypeScript we can bypass this check, so I think having a lint rule might be beneficial for us. I noticed this in one of the tests where the callback was marked as async (t) => but there was no await inside its implementation.

[samccone]

I would rework this rule to be a bit more nuanced, all async function calls should either be

1. prefixed with an await
2. consumed by another fn

for instance

ILovePromises(myAsyncFn());

That means that the following patterns would not error

await foo()
yay(foo);

but

foo()

would

[ljharb]

This eslint rule is horrifically bad and should never have existed in the first place. There are tons of benefits from using async function alone, and forcing use of await both can make code less readable and can force an unnecessary tick (viareturn await`, which is always an antipattern outside a try block)

Similarly, calling a sync function inside an async one is perfectly valid, and trying to force await usage on it will only serve to needlessly slow down the async function. Without type information, this is simply not something that’s safe to even attempt to lint.

[bitpshr]

If I'm understanding this proposal correctly, the intention of this rule is to mandate that async function bodies contain at least one await statement. This is tangentially related to - but different - than mandating how async functions are consumed, which is what I believe @samccone is referring to (which is a valid rule in my opinion, and one that we should track the creation of in another ticket.)

I agree with @ljharb and feel that a rule that mandates that async function bodies contain at least one await statement is too restrictive and could lead to unnecessarily-awaited synchronous statements. It's common to see async functions used for syntactical benefits, such as properly catching and propagating errors in an async function body to a consumer without explicit try / catch wrapping.

[ematipico]

Thank you all for the constructive feedback! As suggested by @bitpshr I am going to open a new ticket to track the rule suggested by @samccone.

We can all agree that forcing an await inside an async function is a bad practice.