feat(eslint-plugin): [no-floating-promises] flag result of .map(async)

[kirkwaiblinger]

PR Checklist

• Addresses an existing open issue: fixes [no-floating-promises] flag .map(async) result #5958
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

This PR adds functionality to the rule to check for unawaited arrays of promises, where we might expect to use Promise.all/Promise.allSettled, etc to handle the result.

async function rejectIn(t: number) {
  new Promise<void>((resolve) => {
    setTimeout(() => {
      resolve();
    }, t);
  });

  throw new Error();
}

// Unhandled rejections. Will now flag.
[1, 2, 3].map(async (t) => {
  await rejectIn(t);
});

I haven't attempted to add editor suggestions for fixes because the fixes seem rather complicated, depending on how you ended up with an array of promises and what you want to do with it. For example, we might fix the above code with

// should we use Promise.all(), Promise.allSettled(), Promise.race(), etc? 
// it's unclear to me that picking one for the user is a good idea.
// Plus, they will still have to handle the resulting promise with catch or something.
Promise.all(
  [1, 2, 3].map(async (t) => {
    await rejectIn(t);
  }),
).catch(() => {});

// This fix would seem plausible but actually violates no-misused-promises with checksVoidReturn: true.
// Also, seems like it would be challenging to implement since it involves inspecting how we got to the
// floating promise in the first place.
[1, 2, 3].forEach(async (t) => {
  await rejectIn(t);
});

// This one should be easy to implement.
void [1, 2, 3].map(async (t) => {
  await rejectIn(t);
});

This seems like enough of an edge case that maybe the user should be responsible for manually resolving it. Please advise if adding editor suggestion would be a requirement for this PR.

[typescript-eslint]

Thanks for the PR, @kirkwaiblinger!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	428b976
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/6571fd7e13e9b8000885b58e
😎 Deploy Preview	https://deploy-preview-7897--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 98 (🟢 up 10 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[kirkwaiblinger]

test case from the issue report

[Josh-Cena]

The tests are great—I cannot devise new test cases. I'll also admit I don't completely understand the problem domain. Just a nit; the error message looks fine to me.

[JoshuaKGoldberg]

LGTM! Very close to approval, just some nits, cleaning up some testing, and (mainly) the message text. I'll wait a bit to approve and then merge in case another maintainer has an opinion on whether to add an option. But this is great stuff!

[JoshuaKGoldberg]