Rule proposal: Ban method override type narrowing

[Woodz]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
• My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Validate that overriden method signatures match the base signature (i.e. no narrowing of types)

Fail Cases

class A {
  f(p: string | number) {
    console.log('A', p);
  }
}

class B extends A {
  f(p: string) {
    console.log('B', p, p.charCodeAt(0));
  }
}

const arrayOfA: Array<A> = [new A(), new B()];
for (const item of arrayOfA) {
  item.f(123);
}

Pass Cases

class A {
  f(p: string | number) {
    console.log('A', p);
  }
}

class B extends A {
  f(p: string | number) { <-- Needs to match base class method signature
    console.log('B', p, p.charCodeAt(0));
  }
}

const arrayOfA: Array<A> = [new A(), new B()];
for (const item of arrayOfA) {
  item.f(123);
}

Additional Info

TS issue was closed as "working as intended" but this is very dangerous, since this breaks some type safety, meaning that this introduces a risk of runtime errors

[kirkwaiblinger]

Huh. Without really having thought about this, my initial impression is that I would have thought that TS would allow subclasses to accept wider parameters and return narrower return types. But if I understand correctly it allows only narrower types both for parameters and return values, is that right?

[Woodz]

Huh. Without really having thought about this, my initial impression is that I would have thought that TS would allow subclasses to accept wider parameters and return narrower return types. But if I understand correctly it allows only narrower types both for parameters and return values, is that right?

Currently TS supports both wider and narrower parameter types. I don't think either should be allowed

[Josh-Cena]

Subclasses accepting wider parameters is safe and idiomatic. Banning it will make some OOP patterns needlessly complicated. Subclasses accepting narrower parameters is because methods are fundamentally unsafe: see https://typescript-eslint.io/rules/method-signature-style/

I'm slightly in favor of such a rule that bans overriding methods accepting narrower input.