freeze, seal and preventExtensions

## The three operations as one ladder JavaScript objects carry two kinds of lockable state: an object-level `[[Extensible]]` flag, and per-property attributes (`writable`, `enumerable`, `configurable`). The three built-ins turn these off in increasing amounts, and each one is a strict superset of the one before it. ### 1. `Object.preventExtensions(obj)` — no new properties Sets `[[Extensible]]` to `false`. From then on: - adding a property fails (silently in sloppy mode, `TypeError` in strict mode); - replacing the prototype fails — `Object.setPrototypeOf` on a non-extensible object throws a `TypeError`; - **deleting** an existing property still works; - **writing** an existing property still works; - **reconfiguring** an existing property still works. ```js const o = Object.preventExtensions({ a: 1 }); o.b = 2; // no new property delete o.a; // true — deletion is still allowed Object.isExtensible(o); // false ``` ### 2. `Object.seal(obj)` — no new, no delete, no reconfigure Seal calls `preventExtensions` and then sets `configurable: false` on every own property. `configurable` is the attribute that governs deletion and descriptor changes, so sealing removes both: ```js const s = Object.seal({ x: 1 }); delete s.x; // false in sloppy mode, TypeError in strict s.x = 2; // allowed — writable is untouched ``` One subtlety: a non-configurable property may still be flipped from `writable: true` to `writable: false` (the only descriptor transition the spec permits once `configurable` is gone). That is exactly how `freeze` is defined on top of `seal`. ### 3. `Object.freeze(obj)` — also no writes Freeze does everything seal does, plus sets `writable: false` on every own **data** property. Accessor properties keep their getter and setter: a frozen object whose `x` is an accessor still runs the setter on `obj.x = 1`, because freeze cannot delete a setter, only make the property non-configurable. ```js const f = Object.freeze({ y: 1 }); f.y = 9; f.y; // 1 Object.isFrozen(f); // true ``` ## The predicates `Object.isExtensible`, `Object.isSealed` and `Object.isFrozen` ask about the current *state*, not about which function was called. An object you built by hand with non-configurable, non-writable properties and `preventExtensions` reports `isFrozen === true`. Two consequences catch people out: - An empty non-extensible object is both sealed and frozen — there are no properties left to violate the condition: `Object.isFrozen(Object.preventExtensions({}))` is `true`. - Since ES2015 these functions accept non-objects: `Object.isFrozen(5)` is `true` and `Object.freeze(5)` returns `5` instead of throwing (ES5 threw a `TypeError` for a non-object argument). ## Shallow, always All three operate on the object's *own* properties only. Nothing recurses: ```js const cfg = Object.freeze({ db: { host: 'localhost' } }); cfg.db.host = 'evil'; // works — cfg.db was never frozen ``` The reference stored in `cfg.db` cannot be replaced, but the object it points at is untouched. Deep immutability requires walking the graph yourself. Data that lives in internal slots rather than in properties is also unaffected: freezing a `Map`, a `Set`, or an instance with `#private` fields does not stop `map.set(...)` or a method from mutating `#count`, because those are not properties at all. ## Arrays Arrays are objects, so all three apply, and the array `length` property is what makes the result feel different. A frozen array has non-writable indices and a non-writable `length`, so `push` fails. Notably `Array.prototype.push` throws a `TypeError` even in sloppy mode, because the algorithm performs a throwing `Set`; a bare `arr[0] = 1` on the same array fails silently in sloppy mode. A *sealed* array still allows `arr[0] = 1` but not `push` or `pop` changing the element count. ## `const` is a different thing `const x = {}` freezes the *binding*: you cannot reassign `x`. It says nothing about the object's properties. `Object.freeze` is the mirror image: the properties are locked, the variable holding the reference is not. Answering "use `const`" to an immutability question is the classic mistake. ## When each is used In practice `Object.freeze` is by far the most used — locking exported constants, enum-like lookup tables, and configuration read at startup, so that an accidental write is either a no-op or a loud failure. `Object.seal` shows up when you want a fixed shape but mutable values (a settings record whose keys must not grow). `Object.preventExtensions` alone is rare and mostly appears as an implementation detail of the other two.