First, this rule is not type-aware and your proposal does not seem to address a core problem that's worth making the rule type-aware, so we are discussing a new rule, not an existing rule extension.

Second, how would that be different from this?

class A {
  a = 1;
}

class B extends A {
  a = 2;
}

Or this?

class A {
  a;
  constructor(a) {
    this.a = a;
  }
}

class B extends A {
  a = 2;
}

Or any other combination of these features? Why is this proposal specific to parameter properties, and not reinitialization of inherited class fields at large? Should we just have a rule that reports all kinds of class field overwriting?

Thanks @Josh-Cena , and I assume in your code snippets, all class B extends class A since currently it's confusing that non-inherited classes are irrelevant to this proposal.

First, I agree with you to treat this proposal as a new rule rather than a rule extension.

Second, IMO rules are about warning developers of potentially unclear and unintentional code. In both of the code snippets you provided:

• It is explicit and clear that field a is overwritten.
• The context is insufficient to determine whether it is intentional by the developer.

However, in the context of this proposal, that is, in the following code:

class A {
  constructor(public a: string) {}
}

class B extends A {
  constructor(public a: string, public b: any) {
    super(a);
  }
}

how would that be different from this?

• The use of parameter-property on class B's public a is proved to be redundant since we see other developers (correctly) omit the modifier public (Please refer to the example we provided in the proposal).
• This specific case suggests an implicit and (most likely) unintentional use and can be fixed without any side-effect.

Should we just have a rule that reports all kinds of class field overwriting?

This proposal is not about class field overwriting. This proposal intends to report an implicitly duplicated re-assignment due to the misuse of the TS feature parameter-property.

Why is this proposal specific to parameter properties, and not reinitialization of inherited class fields at large?

This proposal was inspired by an existing rule no-unnecessary-parameter-property-assignment and intended to cooperate with it to make the guidance on this feature more complete. Retargeting this proposal to general reinitialization of inherited class may be a good idea but developers' intention behind the code and what patterns can be observed are not well-studied as what is in this proposal.

Hope this makes things more clear :)

Should we just have a rule that reports all kinds of class field overwriting?

This proposal is not about class field overwriting. This proposal intends to report an implicitly duplicated re-assignment due to the misuse of the TS feature parameter-property.

Right, and I think what we're saying is:

• The root issue around accidental redundant property re-defines is common to both parameter properties and traditional properties
• There's no need to limit detection for this issue to just one of those two types of properties

I'm mildly in favor of a generalized rule, like no-redundant-property-definitions, for the cases of declaring a property on a derived class with an identical signature to a parent. Slightly reducing one of the original examples:

class Base {
    constructor(public a: string) { }
}

class Derived extends Base {
    constructor(public a: string) {
        super(a);
    }
}

• Playground with Derived extends Base
• Playground with Derived extends Base and useDefineForClassFields

Agreed this new rule would need type information. There are subtle runtime differences, so I don't think the rule couldn't auto-fix. It could only report with suggestions.

P.S. @Josh-Cena I edited in extends A to your class Bs, was that intended?

I'm mildly in favor of a generalized rule, like no-redundant-property-definitions, for the cases of declaring a property on a derived class with an identical signature to a parent.

@JoshuaKGoldberg Did you mean code like:

class A {
  public a: string;
}

class B extends A {
  public a: string;
}

I think this is a good idea that expands the original use case and strengthens the implementation value.

Playground with Derived extends Base and useDefineForClassFields

Thank you for your link, from which I learned that TypeScript can compile a class property declaration to Object.defineproperty.

I also attached a playground link that demonstrates under both compile options, any further audition to class property in the parent class will be reset by the derived class.

And if this rule is going to be expanded to no-redundant-property-definitions, the mixed-use of traditional class property declaration and ts parameter-property should also be detected (The link above demonstrates this).

Coming back to this, we chatted a bit as a team and think:

• This would be valuable in some cases 👍
• Those cases are not very frequent:
  • Although class inheritance is still very much a real pattern in JS/TS, it's slowly becoming less and less popular over time
  • The lack of previously filed issues over the years, or engagement from other community members over this issue's ~2 months, indicates it's not an often-thought-of need

We don't have the maintenance budget to work on every useful-in-some-cases rule proposed. If a lot of community members pitch in over the next few months expressing then that would be a signal we should put this one in scope. If not it might make more sense to tackle as a third-party plugin. I've added the evaluating community engagement label to indicate all that.

Thank you @JoshuaKGoldberg, I agree that class inheritance is slowly becoming less popular, which make this proposal less useful. JS/TS just contains too many features that developers had to choose from.

While waiting for any further community response, may I try to implement it at the same time, and maybe will submit a PR in ~1 month?

You're absolutely welcome to try implementing it, that's a great idea! A lot of rule proposals have been improved -even drastically changed- by prototypes in that way. The one sticking point is that many evaluating community engagement proposals end up closed as wontfix, so a draft PR to tseslint might be extra work on your end that goes nowhere.

Suggestion: you might want to make a third-party plugin that folks can use to try it out. It'd be good marketing to try to get more attention to this issue. Plus if this issue is wontfixed you'd have a plugin folks can use to opt into the proposed rule(s).