What does the TypeScript compiler option `useDefineForClassFields` change about how class fields are emitted, what is its default, and what kind of working code breaks when it becomes true?

## Two possible meanings for one syntax TypeScript had class fields years before they were standardised, and the two designs disagree about what a field declaration *does*. - **Assignment semantics (`[[Set]]`)** — the historical TypeScript behaviour. A field with an initializer becomes `this.x = 1` in the constructor. If a property of that name already exists on the prototype chain as an accessor, the assignment **calls the setter**. A field with no initializer emits nothing at all. - **Define semantics (`[[Define]]`)** — what ECMAScript standardised. The field is installed with `Object.defineProperty`, creating an own, enumerable, writable data property. Setters are **never** consulted, and a declaration with no initializer still defines the property, with the value `undefined`. ```javascript // assignment semantics class A { constructor() { this.x = 1; } } // define semantics class B { constructor() { Object.defineProperty(this, "x", { enumerable: true, configurable: true, writable: true, value: 1, }); } } ``` `useDefineForClassFields` picks which one `tsc` emits. ## The default is tied to target The option defaults to **true when `target` is ES2022 or higher (including `esnext`)** and false below that. That coupling exists so that when you compile to a runtime whose own native class fields use define semantics, TypeScript's emit agrees with it — otherwise the same source would behave differently before and after downleveling. The consequence is the thing to say out loud in an interview: **raising `target` can change runtime behaviour, not just syntax.** A `target` bump from `es2021` to `es2022` is the usual way teams meet this flag, often through a mysterious runtime failure rather than a compile error. ## Breakage one: the uninitialized re-declaration A common pattern re-declares an inherited property to give it a narrower type: ```typescript class Animal { constructor(public name: string) {} } class Dog extends Animal { name: string; // narrowing / documenting the inherited field } ``` Under assignment semantics that declaration emitted nothing, so `Dog` inherited whatever `Animal`'s constructor assigned. Under define semantics it emits a definition after `super()` returns, and the instance ends up with `name === undefined`. The fix is the `declare` modifier: ```typescript class Dog extends Animal { declare name: string; // type-only; emits nothing } ``` `declare` states that the field exists for the type system and that some other code is responsible for it at runtime. It is the correct tool whenever a declaration is documentation rather than initialisation. ## Breakage two: fields versus accessors The second classic pattern overrides a base-class accessor with a derived field: ```typescript class Base { private stored = 0; get value() { return this.stored; } set value(v: number) { this.stored = v; } } ``` Under assignment semantics, a derived class writing `value = 5` invoked the setter. Under define semantics it installs an own data property that **shadows** the accessor entirely — the setter never runs, and later reads bypass the getter. This is a genuine behaviour change, so the compiler reports the conflict rather than quietly emitting the new meaning. When you really want the setter, do the assignment in the constructor body instead of as a field declaration; the constructor body is unaffected by this flag. ## Related consequences - **Ordering and visibility.** With define semantics every declared field exists on the instance immediately after construction, even undeclared-value ones, so `Object.keys(instance)` and JSON serialisation may include keys that previously were absent. - **Parameter properties are unaffected.** `constructor(private id: string)` is a TypeScript-only shorthand that always emits an assignment in the constructor body. - **Decorators.** The two decorator systems observe fields differently; do not reason about one from the other. Whichever you use, the field semantics chosen by this flag is what the decorated member ends up with. ## How to answer well Name both semantics precisely, tie the default to `target`, and give at least one concrete breakage plus its fix (`declare`). The strongest version of the answer notes that this is a rare case where a `target` change alters runtime behaviour — the usual mental model of "target only changes syntax" has exactly this exception.