Actual Result
error

Again, like your last issue, could you please be more specific?
What is the error? What line is it on?

I am unable to repro this against master

@bradzacher I've already added comment at RedirectError's constructor, did you scroll the snippet?

Ah I apologise - I did not see the snippet had more. MacOS hides the scroll bars and the snippet ended perfectly.

This is working as expected - this lint rule does not use type information, only the AST.
And according to the AST - it's a useless constructor as all it does is pass the argument to the super.

Either use a disable comment or make the constructor not-useless

export class RedirectError extends ResponseError {
  constructor(url: string) {
    super({message: url})
  }
}

@bradzacher That's OK, but again the limitation could be documented.

Happy to accept a PR!
If things aren't documented it's usually because it wasn't recognised as a limitation at the time of authoring.
Then so few people run into the limitation that nobody's been motivated to PR it into the docs.

Can you reopen this issue and I'll raise a PR when I'm free, you can assign it to me.

@bradzacher

Like #3796 (comment)

Can we ignore different constructor param names and types? Or at least an option? If you agree, I can try to raise a PR for it/them.

You cannot do this because you don't have access to type information in this extension rule.
Without type information you cannot inspect the parent's constructor arguments.

@bradzacher Well, can we include type information in this rule then? Just like unified-signatures.

It will be a breaking change.

No.

Significant portions of our userbase does not use type-information. This means that introducing it into an existing rule hugely restricts the accessibility of the rule. It is a massive breaking change that likely locks users out of using the rule altogether.

So when we make the decision to add type information, it needs to be for a very good reason and add a lot of value.

In addition - adding it into an extension rule is something we need to make sure we're doing for the right reason. Extension rules exist to add support for TS code to the core rules (in this case - accessibility and parameter properties) - so we want them to be as accessible as possible.

Adding type information to handle this (frankly) very rare case is not worth the cost.

@JounQin are you still planning on sending a PR?

No worries if not, I will soon if you don't have time!

@JoshuaKGoldberg That would be nice! I have no time working on it temporarily.