As always, ESLint helps us not shoot our own foot with a few rules.
In ESLint itself (no plugin)
- no-await-in-loop has good intentions, since it wants to help us avoid inadvertently sequencing parallelizable tasks. But first, it doesn't detect that the promises we await had been created already, which would intelligently combine parallelism and ASAP processing; and second, sometimes we want to sequence async tasks, such as animation steps. So I find this rule to be a bit too heavy-handed and I discourage it.
- no-return-await is about the last anti-pattern we saw earlier, forbidding return await except inside a try/catch. This is good!
- require-await will bark if we have an async function with no await inside. It is indeed superfluous and could even lead to bugs or at least misunderstandings.
In eslint-plugin-promise (set in ES2017+ mode)
Our good friend eslint-plugin-promise, which we saw already in the second part of this course, has two rules specifically for ES2017+ contexts, when async/await is available.
- prefer-await-to-then is nice, as it encourages us to prefer await over manual promise chains. It's generally a good idea.
- prefer-await-to-callbacks is more controversial, because many APIs will only expose a callback-based access to us. Yet it will bark on many callback invocation scenarios (even if it's not for all of them, it's too narrow-minded for most existing API constraints…)