Hi @nicolo-ribaudo !

I can see the argument, but I'm not sure it will make sense for us to support this. We generally don't touch JSDocs. The sort-of exception to this is no-deprecated, which works via TS's type information, rather than us interacting with JSDocs directly, but that isn't available to us here, since unified-signatures isn't type-aware.

My intuition is to think of this as a bandwidth/scope limitation that is best solved with an eslint-disable comment. Curious for thoughts from @typescript-eslint/triage-team.

Blurgh. If unified-signatures was type-aware I think this would be easily something to accept, no complications.

But, since the JSDocs are all in-place, maybe we can fake it? Just go purely off syntax by getting and parsing the JSDoc comments for the nodes themselves? Performance shouldn't be impacted significantly given that it's only one node per overload.

If we entertain this, then I'd ask whether we should generally consider signatures that have different JSDocs 🤔....

Playground

/**
 * This signature does something.
 */
declare function f(x: number): void;

/**
 * This signature does something else.
 */
declare function f(x: string): void;

Yeah I don't think we really want to go into the realm of "partially supporting specific cases of JSDoc and ignoring all other comment contents" cos it does create an inconsistent experience.

I think either we treat JSDoc comments as a marker of uniqueness (behind a default off flag) or we continue to ignore them.

👍 agreed. Marking as accepting PRs for a default-off flag as a feature request for the rule.