Add Rule: no-disconnected-chained-awaits

Please describe what the rule should do: This rule should warn when there are awaits of function calls (including news) next to each other where the awaits do not depend of the values of the previous awaits.

What category of rule is this? (place an “X” next to just one item)

[ ] Enforces code style [ ] Warns about a potential error [ ] Suggests an alternate way of doing something [x] Other (please specify:) If this is the case then the code will run slower since it forces the code to run sequentially when it could run more parallelly.

Provide 2-3 code examples that this rule will warn about:

This would warn:

async function fn() {
    await gn();
    await hn();
    return true;
}

This would warn:

async function fn() {
    const a = await gn();
    const b = await hn();
    return {a, b};
}

This would not warn:

async function fn() {
    const a = await gn();
    const b = await hn(a);
    return b;
}

Why should this rule be included in ESLint (instead of a plugin)? Because with the move towards async/await and promises over callbacks this will be a common mistake for new people. It is also a good catch for experienced developers.

[Nokel81]

The reason why this is the correct why to rewrite them in pure ecmascript is that an await is a blocking call on the promise. Meaning that if a chain of these are in a row then each long action will be done serially.

However, if they are written as the second snippets then both long actions will be sent away and both can complete together

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is a strong consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.