S3735 sonarjs/void-use: False positive on expressions that lead to undefined

Rules and Languages Report False-positive / False-negative...
1

I’m using eslint-plugin-sonarjs@3.0.5, and I believe I identified 2 cases where sonarjs/void-use reports false positives, where the voided value can either be an undefined value or a Promise. Both lead me to the assumption that expressions that can result either in undefined, or another allowed case (e.g. void somePromise), should be allowed.

Case 1 is a function that can either return void or a promise, and the return type should be voidable:

type VoidOrPromiseFunction = () => void | Promise<void>;

const myFunction = async () => {
    return Promise.resolve();
};

const typedFunction: VoidOrPromiseFunction = myFunction;

// ok
void myFunction();

// false positive
void typedFunction();

Case 2 involves optional chaining, where a possibly undefined object has a function that returns a promise. The chain can either resolve to undefined or a promise, both of which should be voidable.

interface SomeInterface {
    someFunction(): Promise<void>;
}
const defined: SomeInterface = {
    someFunction(): Promise<void> {
        return Promise.resolve();
    },
};

const mayBeUndefined: SomeInterface | undefined = Math.random() >= 0.5 ? defined : undefined;

// ok
void defined.someFunction();

// false positive
void mayBeUndefined?.someFunction();
Sonar Community Roundup; Jan 10 - 23, 2026
3

Hi! Thank you very much for the report and the very good examples.

You are right, there is an issue with the rule logic. It does not handle union types like void | Promise<void> or the optional chaining cases correctly. These are common patterns in TypeScript and the rule should allow them.

I have created a JIRA ticket to track this: JS-1135.

We will update the rule to support these cases soon. Also, I will add your examples to our tests to make sure this does not happen again. Thank you again for your time and the clear reproduction!

3 Likes