🤔 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?

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

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..?

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?

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! ❤

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.

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!

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

Great, glad it all worked out! 🙂

@JoshuaKGoldberg I actually closed it by accident haha. I'm getting too bent out of shape so I should move on, but I hope you can understand that this has been frustrating for me, trying to solve a typescript-eslint error one way and then getting a different error, then spending time responding to pushback when I reported the issues...it's been a fair amount of time wasted for code that's valid, safe TypeScript.

Sure, I can understand that. It sounds very frustrating!

If you have the time, I'd love to know - is there anything you think we could have done to signal that we're just requesting info, not pushing back? I'm reading back through the messages and am missing where the perceived pushback is coming from. My intent here was just to learn more about the use case, not to try to indicate to you it's wrong.

No worries if you don't have the time to keep engaging though 🙂

It was mainly Brad saying "How are you using it?... why not just ditch it..?"

For me it's like, imagine if you have some parser error out on weird but valid syntax. You work around it and report an issue, but then the parser maintainer says "why are you even using this weird syntax anyway?" It's beside the point, you never ever want a parser to fail to parse valid syntax.

Not a perfect analogy because things aren't so cut and dry in the world of TypeScript and linting. But I wish this: X | void being valid safe TypeScript were a sufficient reason for y'all to consider this an edge case worth fixing.

Gotcha, thanks - I appreciate the perspective.

But, I do want to push back on your interpretation of Brad's questions. You're right that things aren't cut and dry in the world of linting. Rules like no-invalid-void-type enforce practices that are technically valid TS code but can semantically convey things that aren't intentional. We need to understand the why behind your code snippets to be able to get the right rule behavior. Sometimes what the user is asking for is exactly what should be changed. Other times there's a deeper trend that begets larger changes in the rule - or even other rules.

I empathize that this can easily come across as gruff pushback, even avoidance of responsibility or work on our end. But asking a reporter why they are using it and why they don't ditch it are reasonable and valid questions in this line of work. Both are necessary to understand that why.

In other words: this is how it works for us 😄 we need to ask those questions, otherwise we're not doing our jobs.

Just to document the technical resolution to this, which is somewhat duplicated in the discussion in #10982, the this: void | X union is generally unsafe for the same reason that all void | X unions are, it's just a little tricky to demonstrate it due to this being confusing. At runtime, any value may be in a variable of type void. Therefore, we can write an unsafe function that passes typechecking, but causes a runtime error like so:

(playground)

function unsafe(this: void | PromiseConstructor): void {
  if (this != null) {
    console.log(this.all.name);
  }
}

function unsafelyReturnsVoid(cb: () => void): void {
  return cb();
}

const randomObject = unsafelyReturnsVoid(() => ({ random: 'object ' }));

unsafe.call(randomObject); // runtime error: property 'name' does not exist on undefined.

It's probably a bit of a niche threat since I think you more or less have to use .bind()/.call()/.call() in order to sneak a runtime error past type checking. Perhaps there is some other esoteric this-context trick too 🤷. But, in any case, at first glance it seems "working as intended", with the recommendation being use this: unknown instead and validate the runtime type of this, at least for the implementation signature (more specific overloads are probably good for intellisense and type checking at the function's call sites).

Might make sense to consider a behavior change if a compelling use case is demonstrated.