[no-await-in-loop] should check for `await` keyword inside `forEach` loop

What rule do you want to change?

no-await-in-loop

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

How will the change be implemented? (New option, new default behavior, etc.)? It supposed to include new checks.

Please provide some example code that this change will affect:

function delay() {
  return new Promise(resolve => setTimeout(resolve, 300));
}

async function delayedLog(item) {
  await delay();
  console.log(item);
}
async function processArray(array) {
  array.forEach(async (item) => {
    await delayedLog(item);
  })
  console.log('Done!');
}

processArray([1, 2, 3]);

Output:

Done!
1
2
3

---

Link to read https://lavrton.com/javascript-loops-how-to-handle-async-await-6252dd3c795/

What does the rule currently do for this code? It allows using await inside forEach loop.

What will the rule do after it’s changed? It will warn “Unexpected await inside a loop.”. Probably it makes sense to warn a developer kind used of the loop. (for/of, forEach, etc.).

Are you willing to submit a pull request to implement this change? Yes, it’s a good chance to start contributing eslint.

[dimabory]

@kaicataldo I’ve been thinking how to deal with such kind of buggy code, but TBH I have no idea right now how to enforce this rule 🤷‍♂️ … and yes, you’re definitely right that it has little to do with no-await-in-loop rule.

[eslint-deprecated[bot]]

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.