readonly Members & Field Initialization

## Two different things are being restricted The confusion between `const` and `readonly` disappears once you see that they constrain different things. `const` is a JavaScript declaration form. It creates a *binding* — a name — and forbids that name from ever being pointed at a different value. It has nothing to say about the value itself. `readonly` is a TypeScript-only modifier that goes on a *property* of a class (or of an object type). It tells the type checker to reject writes to that property outside a small allowed window. It cannot be applied to a variable declaration, and `const` cannot be applied to a class member — they are not two spellings of one idea, they are two different tools. ```ts const limit = 10; limit = 11; // Error: Cannot assign to 'limit' because it is a constant class Config { readonly url: string; constructor(url: string) { this.url = url; } } ``` ## Where the compiler allows a write A `readonly` property may be assigned in exactly two positions: 1. Its own declaration initializer. 2. The body of the constructor of the class that declares it. Everything else is an error, including a method on the same class and, importantly, the constructor of a subclass — the privilege belongs to the declaring class, not to the inheritance chain. ```ts class Account { readonly id: string; readonly createdAt = new Date(); // allowed: declaration initializer constructor(id: string) { this.id = id; // allowed: declaring class's constructor } rename(id: string) { this.id = id; // Error: read-only property } } ``` That constructor window is the whole point of the feature: it lets you model a value that is decided once, at construction, and never again. It is the type-level way of saying "this is part of the object's identity". ## Both are shallow Neither modifier reaches inside the value. ```ts class Basket { readonly items: string[] = []; } const b = new Basket(); b.items.push("apple"); // fine — the array itself is not readonly b.items = []; // Error — the property binding is ``` The same is true of `const`: `const cfg = { retries: 3 }` happily accepts `cfg.retries = 5`. If you want the elements protected too, you have to say so in the element type (a `readonly` array type, or a mapped-over type) — the modifier on the outer property does not propagate. ## readonly is erased; const is not This is the point interviewers usually push on. TypeScript emits JavaScript with the type layer removed, and `readonly` is part of that layer. The compiled class has an ordinary writable property; nothing in the runtime object stops a write. `const`, by contrast, is real JavaScript syntax that the engine enforces — reassigning a `const` throws a `TypeError` at run time. So `readonly` protects *your* code while it is being checked. It does not protect an object handed to untyped JavaScript, to a consumer who used a type assertion, or to anything crossing an `any` boundary. ## static readonly `static readonly` marks a class-level constant: it lives on the constructor object rather than on instances, and it may be assigned in its initializer or in a `static` initialization block. It is a common way to give a constant a namespace — `Http.DEFAULT_TIMEOUT` — where a module-level `const` would be a bare exported name. The `readonly` half is still erased; only the `static` member itself survives into the emitted JavaScript. ## Choosing between them Use `const` for every local and module-level binding by default — it is free and enforced. Use `readonly` on class fields that are set at construction and should never change afterwards: identifiers, injected collaborators, configuration snapshots. It costs nothing at run time and turns a class of bugs into compile errors, which is exactly the trade the type layer exists to make. What it does *not* buy you is immutability. If a caller must be unable to mutate the value even from untyped code, that is a runtime concern and needs a runtime mechanism — a private field with only a getter, or freezing the object — not a type modifier.