A TypeScript object whose property is declared `readonly` still gets overwritten at runtime, with no compile error anywhere in the codebase. What holes in the modifier allow that, and what would actually stop it?

## The reproduction ```ts interface Frozen { readonly id: number } interface Mutable { id: number } const f: Frozen = { id: 1 }; const m: Mutable = f; // no error m.id = 2; f.id; // 2 — the readonly property changed ``` Nothing here is a bug in the compiler. When TypeScript checks whether one object type is assignable to another, it compares property names and property types; the `readonly` modifier on a property is **not** part of that comparison. Two aliases to one object, one of which promises not to write and one of which does not, are considered compatible, and the write goes through. This is a documented, deliberate unsoundness. Tracking readonly-ness through assignability would make an enormous amount of ordinary code fail — every function taking a mutable-typed parameter would reject readonly arguments — and TypeScript chose usability. Knowing that it *is* a choice, and not something you can configure away, is the senior-level part of the answer. ## The other two escapes **Shallowness.** The modifier covers the property slot only. Anything reachable through it is untouched: ```ts interface Session { readonly user: { name: string } } declare const s: Session; s.user.name = 'mallory'; // fine — no alias needed, no assertion ``` Most real-world "readonly didn't help" incidents are this one, not the aliasing hole, because it needs no second type at all. **Erasure.** `readonly` produces no JavaScript. So an assertion, a value that passed through `any`, JSON parsed at a boundary, or a call from a plain `.js` file all write without resistance: ```ts (s as { user: { name: string } }).user = { name: 'x' }; // compiles ``` A library consumer who does not use TypeScript is not constrained by your declarations at all. ## The array asymmetry It is worth knowing that `readonly` behaves differently on array types, because the mechanism is different. `readonly string[]` is not "a `string[]` with a modifier the checker ignores" — it is a distinct type that simply does not declare `push`, `pop`, `splice`, or index assignment. Structural checking therefore rejects the dangerous direction: ```ts declare const ro: readonly string[]; const rw: string[] = ro; // error — the mutating members are missing const back: readonly string[] = rw; // ok — the safe direction ``` So the aliasing hole is specific to `readonly` **properties** on object types. Candidates who have only read "readonly is unsound" often over-generalise it to arrays and get this backwards. ## What actually stops the mutation Since no type-layer modifier survives compilation, real prevention is runtime work or structural discipline: - **Freeze the object** before handing it out. That makes the write fail at runtime — silently in sloppy mode, as a `TypeError` in strict mode — and it is still shallow, so a deep guarantee means walking the graph. - **Never expose the mutable reference.** Return a copy, or expose accessor functions instead of the object. If no alias exists, no alias can be typed mutably. - **Deepen the types anyway.** `readonly user: { readonly name: string }` and `readonly tags: readonly string[]` do not close the aliasing hole, but they close the far more common shallowness hole, and they are free. ## How to talk about it The framing that lands in an interview: `readonly` marks a *view*, not a *value*. It is checked only on writes made through that view, only one level deep, and only in code the checker sees. That is genuinely useful — it catches the accidental assignment inside your own module and it documents an API's intent at zero runtime cost — but it is not immutability, and the moment your requirement is "this data must not change", you have left the type system and entered runtime territory. A candidate who names the aliasing hole *and* correctly excludes arrays from it, then separates "catches mistakes" from "enforces a guarantee", has demonstrated exactly the kind of judgment the question is testing.