For reference, now that checker.getAwaitedType is officially documented in TS 5.6 (present since 4.0), I wanted to simplify the rule to just use this:

function isPromiseLike(checker: ts.TypeChecker, type: ts.Type): boolean {
    const awaited = checker.getAwaitedType(type);
    return !!awaited && awaited !== type;
}

That would have caught all cases where TS thinks something is awaitable (unwrapping nested promises and so on), which would have fixed this issue.

checkThenables sort of gets in the way of that ☹️

+1

Doesn't the fastify API use PromiseLike - as in that was the entire problem we wanted to avoid flagging?

It does, #8433 (comment) -> https://github.com/fastify/fastify/blob/dda569960ef2d0961a887ead0e63f4e8671a920e/types/instance.d.ts#L173. But that's just a convenience type - they could always copy just the relevant bits out of it.

I believe @mcollina is out this week and maybe the next, we should ping again the first week of September.

I'm happy for whatever solution that allows us to declare a fire-and-forget promise in a way that does not require a line-by-line or type-by-type configuration and very little user intervention. Setting a config would be fine, even if it would be better if this is enabled by default.

From a practical perspective, any kind of solution that would allow this would work. Note that fire-and-forget promises are part of the language and their design.

On thenables, my opinion is that a Thenable does not imply behavior, just that it has a .then() method and it is therefore awaitable. It does not imply any Promise semantics, and the spec in fact "wraps" them in a promise internally. Therefore typescript-eslint should not assume anything more about them, specifically, that they must be awaited to avoid errors.

The important part is that you can declare a .then() method into any object, and then you would need to immediately see a lot of errors from typescript-eslint.

Is there a known benefit to making this change in terms of use cases where the rule would flag, rather than implementation simplification on our side?

While the idea of flagging PromiseLikes sounds perfectly sensible, if it just runs into the fastify edge case again, without offering some other benefit, inaction may be better than action 🤔.

(i take back my +1 and am back to undecided, since I didn't recall that the fastify case was PromiseLike, thanks @bradzacher for pointing that out 👍 )

👍 I too would like to see a use case for checking PromiseLike too.

I'm also +0. Either treat all thenables as promises or don't.

I personally would love for us to do this and simplify our logic to better align things with TS -- but it's just a hard sell for us to make this switch whilst there are known usecases in the community where we don't want to report on a "thenable" thing (eg fastify, node:test).

With that being said -- we could probably apply this change to the following without anyone being upset

no-misused-promises:

await-thenable:

Chatted internally with the team. tl;dr: we're going to wontfix this for no-floating-promises and file a separate issue for other rules. Although we'd prefer to be more strict and catch more issues by default, we don't want to be disruptive to frameworks using PromiseLikes.

For visibility, summarizing our perspective and conversations such as #8433 (comment) after the ---...

We're not super enthused about intentionally building in such an escape hatch to the rule. The userland convention most of the time for Promise -and, to almost the same extent, the PromiseLike type- is that it's a task whose result the calling code should care about. Which means it should be awaited. This convention was settled on well before typescript-eslint and is still in use by most users.

The tricky thing is, there are a few frameworks -Fastify, node:test, RTK- that intentionally go against that convention. These frameworks have a select few APIs that intentionally use Promises as "fire-and-forget" indicators. Users don't need to await those function calls; they can just choose to do so if it's useful to them. There's no language-level delineation in JavaScript or TypeScript between a standard Promise vs. a "fire-and-forget" one. So the frameworks just type their code as Promise.

This presents a problem for linters such as typescript-eslint. We definitely can't turn no-floating-promises off by default because most of the time it's extremely useful. Fun fact: it's the single most requested rule that gets brought up in our support conversations with companies and with native speed linters about type-checked linting. But, since there isn't a way to delineate between standard vs. a "fire-and-forget" task, that means these framework "fire-and-forget" ones get falsely reported on by default. Which brings up the request: how do we make no-floating-promises by default report standard tasks, but not "fire-and-forget" tasks?"

My 🌶 hot take is that the best situation would have been for frameworks not to co-opt the Promise types to mean a "fire-and-forget" task. It contradicts existing user conventions and thus causes inconvenience for users trying to integrate the frameworks with typed linting. My recommendation is to use some other API design, such as an .on listener or returning an object whose property is the task.

But, assuming the API must use "fire-and-forget" Promises -either for legacy reasons or because I'm just blatantly wrong in that recommendation- then there are some strategies folks can take to avoid lint reports with no-floating-promises:

• End-user solution: end-users can use @typescript-eslint/no-floating-promises allowForKnownSafeCalls option to allowlist specific functions from a library
  • Example: typescript-eslint/examples > node-test-floating-promises
• Framework + end-user solution: if a framework uses a specific type for its Promises such as a branded type, end-users can use @typescript-eslint/no-floating-promises allowForKnownSafePromises option to allowlist everything of that type
  • Draft examples: feat: add redux-toolkit-floating-promises example examples#20, feat: add fastify-floating-promises example examples#22
• Framework solution: using the PromiseLike type to represent their runtime Promises, which is roughly as accurate but less precise than the Promises
  • Note that this solution does not avoid type errors when the checkThenables option is enabled. That option is not turned on by default: Enhancement: [no-floating-promises] Don't check coincidentally Promise-like (Thenable) type values by default #8433 -> Enhancement: [no-floating-promises] Disable checkThenables by default in v8 #9508

Separately: I've also filed #10666 and commented #10666 (comment) for the occasional request for typescript-eslint to provide its own SafePromise type.