Before You File a Proposal Please Confirm You Have Done The Following...

• I havesearched for related issues and found none that match my proposal.
• I have searched thecurrent rule list and found no rules that match my proposal.
• I haveread the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/no-floating-promises

Description

Forwarding out from conversations with@mcollina, especiallynodejs/node#51292 (comment): right nowno-floating-promises will consider anything thatlooks like a Promise (i.e. is "Promise-like") to be a potential floating value:

But to my knowledge this hasn't been particularly helpful. If somethingcoincidentally happens to match theThenable interface that doesn't necessarily mean it shouldn't float!

The historical context here is that it used to be common in JavaScript code to use alternative implementations of Promises, such asBluebird. Promises were only added to some browsers in ~2014 and Node & co in ~2015 or so. Many sites still had to support old versions of Internet Explorer. Theno-floating-promises typescript-eslint rule was implemented in 2019 when it was still not-unheard-of to use alternative Promises or at least have Promise types provided by a polyfill:#495.

Now that the vast majority of projects are using built-in Promise values & types, I think the value of detecting those values automatically is no longer worth the pain of flagging general thenables. I propose we modify the rule to:

• (non-breaking) Add in an option to specify types to be considered Promises - using the same standard format asEnhancement: [no-floating-promises] add an 'allowForKnownSafePromises' option #7008
• (breaking, as a followup issue & PR for v8) Change the rule to no longer detect Thenables, and instead only look for the built-inPromise type
  • Nuance: should users be able toremove the built-inPromise type from the list of checked types? I don't think so, but that's not a decision we'd need to make now...

I.e. this is the opposite of#7008. That issue is about adding an allowlist for types to be allowed to float. This one is adding a blocklist of types tonot be allowed to float - instead of always detecting Thenables.

Fail

declarefunctioncreatePending():PromiseLike<void>;createPending();

Pass

declarefunctioncreatePending():Promise<void>;createPending();

Additional Info

After the proposed followup, if folks still want to detect floatingPromiseLikes, they'd be able to use this option.

As to whether we'd want to give users a way to opt back into the current"check anything that looks like a Thenable" behavior... I don't see why anybody would want that, but we could always make it an option if someone asks for it.