Readonly, const Assertions & Immutability

interface Point { readonly x: number; readonly y: number; }
const p: Point = { x: 1, y: 2 };
// p.x = 5; // Error: cannot assign to 'x' because it is a read-only property
p.x; // fine to read

Common follow-ups: Does 'readonly' provide any actual runtime enforcement, or is it purely compile-time?

const nums: readonly number[] = [1, 2, 3];
// nums.push(4); // Error: 'push' does not exist on type 'readonly number[]'
// nums[0] = 99;  // Error: index signature is read-only

Common follow-ups: Which specific array methods remain available on a readonly array type, versus which are removed?

const config = { theme: 'dark', maxRetries: 3 } as const;
// theme: 'dark' (literal), not string
// maxRetries: 3 (literal), not number
// config.theme = 'light'; // Error: readonly

Common follow-ups: Without 'as const', what wider types would 'theme' and 'maxRetries' have been inferred as instead?

interface Point { readonly x: number; }
const p: Point = { x: 1 };
(p as { x: number }).x = 99; // bypasses readonly via a type assertion, mutates fine at runtime
console.log(p.x); // 99

Common follow-ups: How would you combine 'readonly' with Object.freeze() to get BOTH compile-time and runtime immutability?

const colors = ['red', 'green', 'blue'] as const;
// inferred as: readonly ['red', 'green', 'blue']
// NOT string[], and NOT a mutable array

Common follow-ups: How would you derive a union type like 'red' | 'green' | 'blue' FROM this const-asserted array automatically?

const config = Object.freeze({ theme: 'dark', retries: 3 });
// config is typed as Readonly<{ theme: string; retries: number }>
// config.theme = 'light'; // Error at compile time AND fails/throws at runtime

Common follow-ups: Does Object.freeze() perform a deep freeze, or only a shallow one — and what does that mean for nested objects?

type DeepReadonly<T> = T extends (infer U)[]
  ? readonly DeepReadonly<U>[]
  : T extends object
    ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
    : T;

interface Config { server: { port: number } }
type Frozen = DeepReadonly<Config>; // server AND server.port are both readonly

Common follow-ups: Why might a naive DeepReadonly implementation behave incorrectly on special object types like Map, Set, or Date?

function getConfig() {
  return { theme: 'dark' } as const; // correct: applied directly to the literal being returned
}
// NOT: const result = getConfig() as const; -- this wouldn't add any extra narrowing beyond what getConfig() already returns

Common follow-ups: How would you type a factory function to return a precise literal-typed object without needing to manually repeat 'as const' at every call site?

const THEMES = ['light', 'dark', 'system'] as const;
type Theme = typeof THEMES[number]; // 'light' | 'dark' | 'system'

function setTheme(theme: Theme) { /* ... */ }
setTheme('dark'); // OK
// setTheme('blue'); // Error: not assignable to Theme

Common follow-ups: Why is this pattern generally preferred over maintaining a separate array AND a separate manually-written union type?

interface Animal { name: string; }
interface Dog extends Animal { breed: string; }
const dogs: Dog[] = [{ name: 'Rex', breed: 'Lab' }];
const readonlyAnimals: readonly Animal[] = dogs; // sound and safe: read-only, so no invalid inserts possible
const mutableAnimals: Animal[] = dogs; // TypeScript allows this too, but it's technically unsound

Common follow-ups: Why does TypeScript still allow the unsound mutable-array assignment despite readonly being the technically correct direction?