• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

To support this issue, I've created a sample repository to show the problem. The main issue is with types that support a "builder pattern". In other words, you can continually build onto a given object until you're ready to execute it with a .then or await.

{
  "rules": {
    "@typescript-eslint/no-floating-promises": "error"
  }
}

There are two issues displayed in this use-case.

1. Fastify. Fastify causes two classes of errors to be thrown in this example. The first is with .register. This one can pretty easily be ignored by adding a void in front of it. However, all of the Fastify examples don't show the need to await the returned promises. The second issue is with their FastifyReply object, which is likely more interesting to think about. It uses a builder pattern, allowing you to set properties before your file res.send. Each line adds a warning before the final send, unless you add voids.

2. Knex QueryBuilder. The other issue displayed here is with the Knex QueryBuilder. Knex allows you to pass around a QueryBuilder object before finally await-ing it to execute the query. Again, these errors can be supressed with a void until you're actually ready to execute the query.

import Fastify from 'fastify';
import FastifyCookie from 'fastify-cookie';
import knex from 'knex';

const dbClient = knex({});
const app = Fastify();

// The docs for Fastify don't show a need to `await` these calls to `register`.
// It would be nice to be able to safelist these usages somehow.
app.register(FastifyCookie);

app.get('/example', (_req, res) => {
  // You're able to build up your response over multiple lines. These throw
  // linting errors since the FastifyReply type has a `then` method.
  res.header("x-some-header", "foobar");
  res.send(200);
})

app.get('/dbquery', async (_req, res) => {
  // This one is a bit tougher to think about solving for, since eventually
  // you'd want to validate that it's `await`-ed. However, it would still be
  // nice to provide some way to just ignore these types all together.
  const query = dbClient('foos');
  query.orderBy('id', 'desc');
  const dbResult = await query;
  res.send(JSON.stringify(dbResult));
});

app.listen(4000);

{
  "compilerOptions": {
    "target": "es2019",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Expected Result

It would be nice to be able to ignore certain types from producing errors. In this case, it'd be nice to be able to safelist the FastifyReply type from producing warnings in this plugin.

Actual Result

  10:1  error  Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises
  15:3  error  Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises
  16:3  error  Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises
  24:3  error  Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises
  26:3  error  Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises
  29:1  error  Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises

Additional Info

I can work around this by placing void in front of each of the calls I want to ignore. However, this is more of a feature request/brainstorming issue to think about ways we could reduce cluttering the code with void statements in all of these cases.

Is this even something to consider fixing? Or maybe adding the void in front of all calls to builder methods is explicit and desired?

Versions