Version

21.5.0

Platform

n/a

Subsystem

node:test

What steps will reproduce the bug?

1. Write code that calls adescribe,it, ortest function imported fromnode:test
2. Lint that code with@typescript-eslint/no-floating-promises enabled

I put a standalone repro onhttps://github.com/JoshuaKGoldberg/repros/tree/node-test-no-floating-promises. From its README.md:

import{it}from"node:test";it("",()=>{});// Promises must be awaited, end with a call to .catch, end with a call to .then with a rejection handler or be explicitly marked as ignored with the `void` operator.// eslint(@typescript-eslint/no-floating-promises)

How often does it reproduce? Is there a required condition?

100% of the time. The most common workarounds are to either disable the rule in test files or usethe rule'signoreVoid option.

What is the expected behavior? Why is that the expected behavior?

@typescript-eslint/no-floating-promises is enabled in theplugin:@typescript-eslint/recommended-type-checked config that isrecommended to users as part of typed linting. I was expecting that the built-in functions for Node.js wouldn't directly trigger complaints in the built-in presets for typescript-eslint.

What do you see instead?

Lint failures out of the box.

As for what should be done: I'm not sure 🤔. If it were just up to me, I'd say switching the functions to have void returns ... or failing that, having their@types/node types changed to returnvoid to indicate the returned values shouldn't be used.

How intentional is it that the functions' returned values are made available to users? I can see an argument that returning a Promise that rejects or resolves is a potentially useful feature for the functions...

Additional information

I wasn't sure whether to file this as an issue or discussion. It feels like anissue to me because common practice for many TypeScript projects has been to enable this rule, or previouslyTSLint'sno-floating-promises. But I'm not a Node.js expert - apologies if I'm off base 🙂. If the rule is wrong to complain for some general-to-JavaScript reason, then I'd be happy to take lead on a general bug in typescript-eslint.

We first received this as a bug report intypescript-eslint/typescript-eslint#5231. We wontfixed that as it's not a good idea for a linter to add framework-specific behaviors. We're instead discussingadding anallow option to@typescript-eslint/no-floating-promises. But, that wouldn't be ideal for users IMO because then everyone would have to add an explicitallow to their ESLint configs or use a shared config/preset.