Bug: [no-invalid-void-type] false positive on this: X | void annotation

[jedwards1211]

Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have searched for related issues and found none that matched my issue.
• I have read the FAQ and my problem is not listed.

Playground Link

https://typescript-eslint.io/play/#ts=5.7.2&fileType=.tsx&code=KYDwDg9gTgLgBDAnmYcAKUIFsCWBnYAdRxgAsAlYPCAGwDdgo8AeAFQD44BeOAbwCg4cAPTC4AOkn8Avv37CAVAsEK4AVQJQaAQwB2AEzg4sYGsCzBdMbTBwRdcCADM4AbQzZ8wcQHcSFKloGJgBdXgABGhxdAGs4UhgYMDwALlF9YAYaCBQocSwIAC8cGh1xaABzYUsAWjUAZWF9CABjPGFCYAAjYQApbTptepaoHDAYYUonRksW4GEAcWyu7RoAfQB5LoArYBaYdo9cAmE-MkpqekY8aXEVOA3dObgfVABXMAqobQyECDgAHIQX4AJhBABoXqgWno4Hgzi1SH8EKRUF03iVbLo7nAFMJ%2BKBILA4E43k9bPYXv4LkFrmx2AAKQQo-ApdCYY7AADC9jwMCgb320DgAB84HQIDh9PwAJRso5eYjnQJXJj0vjMqDAGBvKAOARCISiCRSISyWRAA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1uYDcBDRgBNaPDpWFFS6KImjQO0SODABfECqA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

Repro Code

export type PromiseWithResolvers<T> = {
  // ...
}

/**
 * Userland implementation of [Promise.withResolvers]{@link https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/withResolvers}.
 * Once we upgrade to Node 22, we can switch to the builtin.
 */
export function withResolvers<T>(
  this: PromiseConstructor | void
): PromiseWithResolvers<T> {
  return {
    // ...
  }
}

ESLint Config

module.exports = {
  parser: "@typescript-eslint/parser",
  rules: {
    "@typescript-eslint/no-invalid-void-type": "error",
  },
};

tsconfig

{
  "compilerOptions": {
    // ...
  }
}

Expected Result

No error

Actual Result

void is not valid as a constituent in a union type 10:30 - 10:34

Additional Info

This is the only possible way to type an optional this binding other than function overloads, but function overloads trigger @typescript-eslint/unified-signatures.

[JoshuaKGoldberg]

🤔 Interesting, I've seen ponyfills and wrappers for withResolvers before but never with a union type for this. Could you please explain why you went with this type? Also, why not PromiseConstructor | undefined?

[jedwards1211]

I don't remember where I got it from, but probably the idea was you could call withResolvers() (TS only accepts this: void in that case, not this: undefined) or withResolvers.call(thirdPartyPromiseConstructor). It may be unusual but it's never fun when it's impossible to satisfy both TS and typescript-eslint, I hope it's always your goal to avoid that

[bradzacher]

I'm not sure I understand, when you say "but probably the idea was you could call withResolvers()" -- what do you mean "probably"? How are you using it?

If you don't intend to use the .call style -- why not just ditch it..?

[jedwards1211]

Argh, can we focus on thoroughness? I copy pasted the code, thought typescript-eslint's behavior didn't make sense, and decided to report it so that we can make typescript-eslint more robust for the next person who really does need this kind of typedef, but it sounds like you just don't want to go to the trouble? How about I work on a PR for this?

[JoshuaKGoldberg]

can we focus on thoroughness?

That's what we're trying to do 😄. You've posted an issue with some context and a partial explanation that we're interested in hearing more about. We can't reasonably take action until we understand:

• What exactly is your code doing?
• What are the alternatives?
• Why are those alternatives not suitable?

it sounds like you just don't want to go to the trouble?

It's that we want to be thorough and understand something fully before jumping to action and applying a potentially insufficient -or even wrong- solution. As with #10982, help us help you. The better you can explain why you want a thing to happen, the more we can help in making it happen.

decided to report it

By the way, we do really appreciate you reporting this. For every one report there are almost always scores of people who just rolled their eyes and moved onto something else with a workaround / disable comment. Thank you for working with us! ❤

[jedwards1211]

I certainly have alternatives here -- my main goal is to cut down on everyone's time spent dealing with nuisance errors, especially when turning on typescript-eslint for the first time. I want to adopt the recommended defaults just in case, but only a few things like no-floating-promises have caught bona fide bugs for me yet. You might see it as a win if I remove the this overload I'm not using, but to me, it wasn't a great use of time because this is valid, safe TypeScript.

My thinking is just, do I know why someone would need to type a function that may or may not be called with a specific this binding? No, but if they do, should they get stuck in a catch-22 of having to disable one rule or another? Also no...

I can understand an argument that overloading this is a weird pattern and there are usually less weird ways to solve any given problem, but TypeScript supports this pattern and can ensure it's safely used, so I don't see why we should blow it off just for being niche.

[JoshuaKGoldberg]

I don't see why we should blow it off just for being niche.

We're not blowing it off for being niche. We're trying to understand what the purpose of it is, to evaluate how best to support it. Please give us the information we're requesting so we can help support the use case you're requesting. Or, if you don't have that information, let someone who does post so we can have a productive discussion. Thanks!

[jedwards1211]

What are the alternatives?

Removing the explicit this type

Why are those alternatives not suitable?

Because I was trying to churn through a bunch of eslint errors, removing the this type wasn't my first instinct - it took some digging to confirm that it wasn't needed. My first instinct (in #10982) was to try to unify the function overloads, but then I ran into this error. At this point, the amount of time I had spent on these pesky decisions was unsuitable enough to me that I felt motivated to report an issue, instead of just moving on

[JoshuaKGoldberg]

Great, glad it all worked out! 🙂