TypeScript reports "Property 'name' has no initializer and is not definitely assigned in the constructor" on a class field. Which compiler check produces that error, and what are the legitimate ways to satisfy it?

## What the check is The error comes from `strictPropertyInitialization`, one of the checks that `strict` turns on. Its rule: every declared instance field whose type does not admit `undefined` must be provably assigned by the end of the constructor. If the compiler cannot prove it, you get "Property 'x' has no initializer and is not definitely assigned in the constructor". It depends on `strictNullChecks`. Without null checking, `undefined` is assignable to `string`, so "the field might be undefined" is not a statement the type system can even make — and the compiler refuses the combination, telling you `strictPropertyInitialization` cannot be specified without `strictNullChecks`. ## Why it exists Without it, this compiles and lies to you: ```ts class User { name: string; // never assigned } new User().name.toUpperCase(); // TypeError at run time ``` The declared type says `string`, the runtime value is `undefined`, and every downstream call site trusts the declaration. The check closes the most common way a class hands out a value that does not match its own annotation. ## The analysis is constructor-body-only This is the part interviews probe. The compiler performs a control-flow analysis over the *constructor body itself*. It does not follow calls. So the extremely natural refactor below still errors: ```ts class Session { token: string; // Error: no initializer, not definitely assigned constructor() { this.init(); } private init() { this.token = "abc123"; } } ``` The assignment genuinely happens, but proving that would require inter-procedural analysis the checker does not attempt — and could not do soundly, since `init` is overridable. The fix is either to inline the assignment into the constructor or to have the helper return the value: `constructor() { this.token = this.makeToken(); }`. ## The ways to satisfy it, and what each costs **Initializer.** `name = "anonymous"` — the simplest and the one to prefer when a sensible default exists. Costs nothing. **Constructor assignment.** `constructor(name: string) { this.name = name }` — the normal shape for a value that comes from the caller. Also satisfied by an assignment inside a branch, as long as every path through the constructor assigns. **Widen the type.** `name: string | undefined` or `name?: string`. This is the honest option when the field really can be absent: it changes the type, so every reader is now forced to narrow before using it. That extra work at the call sites is the *feature*, not the cost — but it is a contract change, so it is the wrong answer when the field is genuinely always set. **Definite assignment assertion.** `name!: string` keeps the type as `string` and tells the compiler to stop asking. Nothing is verified; you have taken on the obligation personally. It is legitimate when something outside the constructor reliably populates the field — a dependency-injection container, a framework lifecycle hook, a test fixture's setup function — and indefensible when it is used to bulk-silence errors, because it produces exactly the lie the check was written to catch. **declare.** `declare name: string` says the property exists but this class does not create it and the compiler should emit nothing for it. Used for fields supplied by a base class or an external mechanism. **abstract.** An `abstract` property is a requirement placed on subclasses, so the abstract class is not expected to initialize it. ## Reading the error as a design signal Most occurrences of this error are the type system asking a real question: is this field always present, or not? If the answer is "always", move the assignment into the constructor. If it is "not until later", say so in the type and let readers deal with it, or model the two states as separate types rather than one type with a hole in it. Reaching for `!` first turns a design question into a suppressed warning, which is why a blanket `!` habit reads badly in review. ## Practical note The check looks at declared fields. A property that only ever appears as `this.something = ...` inside a method, with no declaration at all, produces a different error — the property does not exist on the type — and the fix there is to declare it, at which point this check applies to it too.