Initialization of property in base class not recognized by sub class after redefinition

[Pandawan]

TypeScript Version: 3.7.3

Search Terms: extends, constructor, class, overriding, assigned, properties, jsdoc, documentation

I'm not sure if this is an actual bug as this is related to #1617 but is not exactly the same case.

I have a base class and a sub class which extends the base one. My goal is to override the JSDoc of one of the base's properties but keeping everything else intact. So I simply thought of declaring the exact same property on the subclass and change the JSDoc:

Code

class BaseClass {
    /**
     * Val in base
     */
    public val: number;
    constructor() {
        this.val = 5;
    }
}
class SubClass extends BaseClass {
    /**
     * Val in sub
     */
    public val: number;
    constructor() {
        super();
    }
}

Expected behavior: I'd expect everything to work since the constructor of the base class already sets val to 5 and is clearly called in the constructor.

Actual behavior: I get a Property 'val' has no initializer and is not definitely assigned in the constructor. ts(2564) in the sub class.

In a way, this makes sense because this error refers to val of the subclass, which isn't being assigned. But at runtime, everything will work fine (thanks to the prototype chain).

If this is intended, I'd like to know if there's any way to achieve the same result but without having to re-assign val inside the constructor. Essentially, I just want to replace the JSDoc of val in the sub class.

Playground Link: https://www.typescriptlang.org/play/?ts=Nightly#code/MYGwhgzhAEBCkFMDC4rQN4Cho+gegCoDtdoDoA1MEaASwDtoAjRE3AvN6ABwFcmQtYNABu1AFzR6vALZMEAJwDcXYAHt6EAC4LewLWoUAKAJQYupLQAtaEAHRiaAXmgBWFaQC+mb6EgwAZX4Uf2gEAA8tBHoAExh4CGRUGCxSQmJSMkpqOkYIfgsOLj4BIVEJKVl5ZVUNbV19Q1NzTNx87kVTD1xvTyA

Related Issues: #1617, #21775, #20911 (this issue might be a duplicate of one of these, sorry)

[rafaelkallis]

I also run into the same situation and look for a solution.

In contrast to @pandawanfr , I run into this situation because I want to apply a class property decorator to a parent class property.

Suppose I have a parent class Entity which has decorators applied to properties for validation. A child class TypeOrmEntity applies additional decorators to properties.

abstract class Entity {

  @IsString()
  @MaxLength(24)
  public id: string;

  constructor(id: string) {
    this.id = id;
  }
}

abstract class TypeOrmEntity extends Entity {

  @PrimaryColumn()
  public id: string; // strict property initialization warning

  constructor(id: string) {
    super(id);
  }
}

[chharvey]

@pandawanfr — I don’t think it’s good practice to redeclare an inherited field on a subclass. To fix the error, you can remove the redeclaration. If the field is public/protected, you can still access it in the subclass.

class BaseClass {
    /**
     * Val in base
     */
    public val: number;
    constructor() {
        this.val = 5;
    }
}
class SubClass extends BaseClass {
    /**
     * no need to redeclare Val in sub
     */
    // [REMOVE] public val: number;
    constructor() {
        super();
    }
    test(): void {
        console.log(this.val); // still visible within subclass
    }
}

[Pandawan]

I know, but as stated in my original question, my goal is to “override the JSDoc of one of the base's properties but keeping everything else intact.”

I’m pretty sure the only way to change the JSDoc of a property in TS is to have it right before the property declaration, therefore I HAVE to redeclare it in the subclass.

Also, @rafaelkallis is encountering a similar issue, he wants to apply an extra decorator to a property that is defined in the base class.

EDIT: Tho in the case of property decorators, they might be modifying/restricting the type of the property to a point where the base & sub no longer match exactly, in which case the error makes sense.

[RyanCavanaugh]

You can write

    declare public val: number;

to do this

[Pandawan]

That solved it for me, thanks! (Sorry for bothering you with that). I’ll wait a bit before closing in case @rafaelkallis has something to say.

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

[thw0rted]

@RyanCavanaugh if that does what it looks like it does, I think I'm going to use this a lot. Thanks! I wrote a bunch here about how I couldn't find the docs for it but then I stumbled across this part of the 3.7 release notes. 👍