A TypeScript class targeting ES2022 subclasses another and redeclares an inherited property just to give it a narrower type — `class Dog extends Animal { name: string; }` — and at run time `name` comes out `undefined`. What is the compiler doing, and how do you fix it?

## Two emit strategies for a class field A class field declaration can be compiled two ways, and TypeScript picks between them with `useDefineForClassFields`. With the option **off**, fields are emitted as assignments in the constructor — `this.name = ...` — and a declaration with no initializer emits *nothing at all*. This was TypeScript's original behaviour, from before class fields existed in JavaScript. With the option **on**, fields follow the standard JavaScript semantics: each declared field is *defined* on the instance, and one without an initializer is defined with the value `undefined`. Nothing is skipped; a bare declaration is still a runtime operation. In modern TypeScript the option defaults to `true` when `target` is ES2022 or higher (including `esnext`), and `false` for lower targets. That default flip is why this bug shows up when a project raises its target rather than when anyone touches the class. ## Why the redeclaration wipes the value Order of operations inside `new Dog()`: 1. `Dog`'s constructor runs `super(...)`. 2. `Animal`'s constructor runs and assigns `this.name`. 3. Control returns to `Dog`, and *now* `Dog`'s own field definitions execute. 4. `name: string` — no initializer — defines `name` as `undefined` on the instance. 5. The rest of `Dog`'s constructor body runs. The subclass author thought they were writing a type annotation. They were writing an instruction to create a property. The base class's work is discarded between steps 2 and 4. ```ts class Animal { name: string; constructor(name: string) { this.name = name; } } class Dog extends Animal { name: string; // emits a field definition -> undefined constructor() { super("Rex"); } } new Dog().name; // undefined ``` ## The compiler tells you This is not silent. When the define semantics are in force, TypeScript reports that the property will overwrite the base property in the base class, and suggests adding an initializer if that is intentional, or a `declare` modifier — or removing the redundant declaration — if it is not. The failure mode in real projects is that the message is read as a style nag and suppressed. ## The fix: declare ```ts class Dog extends Animal { declare name: string; // type-only restatement, emits nothing constructor() { super("Rex"); } } ``` `declare` on a class property tells the compiler the property exists at run time by some other means and that it must not emit anything for this declaration. It is the correct tool whenever you are restating a member the base class already creates — most often to narrow its type in the subclass, which is legal as long as the narrower type is assignable to the base's. It is also the standard fix for the same problem coming from the other direction: a framework or a decorator populates the property, and you only want the type on record. ## The accessor variant The same mechanism breaks a subtler case. If the base class exposes the member as a getter/setter pair on the prototype, a subclass field declaration under define semantics creates an own data property on the instance that *shadows* the accessor — and, because defining is not assigning, the base setter is never called. Code that expected the setter's validation or side effect gets neither, and reads now hit the shadowing own property instead of the getter. `declare` fixes this one too. ## Judgement Two things are worth saying out loud. First, this is the standards-compliant behaviour: the define semantics are what JavaScript itself specifies for class fields, and TypeScript's older assignment emit was the deviation. Turning the option off to make a bug go away is buying time against the language, not fixing anything. Second, this is exactly the kind of defect the type-erasure model is supposed to prevent — a declaration in the class body that looks like an annotation but is not. The habit to build is: in a class body, a field declaration is a runtime instruction unless you write `declare`.