Now answering as a team member: I don't think this would be good, and here's a long explanation why...

We in typescript-eslint do not decide userland best practices or conventions. It would be inappropriate for us decide these things: we're not the universal experts of everything and are certainly not qualified to represent the vastness of the JS/TS world's various frameworks+libraries+tools. Rather, we attempt to represent the best practices and conventions that already exist in userland. We do our best to drop our personal biases -e.g. I abhor allowing void exemptions to no-floating-promises- and act fairly. We don't always succeed because we're human (and grossly underfunded as a team, hooray open source!), so our GitHub issues are always open for input. In other words, we try to interpret ecosystem-at-large needs and encode those into our rules: not the other way around.

The distinction is important because I don't want people to come away from these discussions thinking that we in typescript-eslint made a decision for the community, or that the aforementioned workarounds in frameworks are purely because of typescript-eslint. We just happen to be the only mainstream linter right now with a fully working no-floating-promises rule. The same issues happened in the past with TSLint and will happen in the future once Biome, deno lint, Oxlint, and others add typed linting as they all plan to.

All that is why we have not been in favor of adding a branded type like SafePromise to typescript-eslint itself. It would be inappropriate for us to tell "fire-and-forget" frameworks "we will report on your code by default unless you take a dependency on our package and use our type". typescript-eslint is not the conceptual source of linting for floating Promises: JS/TS + userland is. And even if we were willing to make that compromise, the same issue would pop up for every other typed linter implementing no-floating-promises. Linters would all have to either:

• take a dependency on typescript-eslint - which is politically bizarre
• provide their own SafePromise equivalent - which means frameworks would have to take an additional dependency for each linter
• create some linter-agnostic SafePromise type - which is something nobody has initiated successfully
  • This could exist in a third-party package, which would be a heck of a lot of work to get adopted across the ecosystem
  • This could exist in TypeScript's types itself, but I would be surprised if they accepted a suggestion given how there's no actual runtime difference, and the "fire-and-forget" delineation isn't encoded into JavaScript

Putting it all together: IMO 👎 we shouldn't provide a SafePromise type ourselves. If one is separately established in the community, we could use that.

It's been >3 months since we added the evaluating community engagement label to this issue. In that time, we have not seen any engagement in favor of this feature request. We're still of the opinion that if something like this exists it cannot come from a single linter team like us -- it'd need to be centralized and/or from a community consensus.

Closing out as out of scope for this project. If anybody has significant new information for the issue of a built-in "SafePromise" type or similar, such as community consensus on a single type, please do post back in a new issue. We'd be happy to take a look.

For folks who want a no-floating-promises rule that respects a SafePromise type, you're welcome to use the docs in https://typescript-eslint.io/developers to build a rule/plugin that has that. You can always fork the rule from tseslint.

Cheers! 💖