When would you reach for a JavaScript WeakSet, and what can you not do with one?

## The one job it does well `WeakSet` is membership without ownership. It records that an object belongs to some group, holds it weakly so the record cannot extend its life, and offers three methods: ```js const ws = new WeakSet(); const obj = {}; ws.add(obj); // returns the set, so calls chain ws.has(obj); // true ws.delete(obj); // true ws.size; // undefined — no count exists ``` Members must be objects, or unregistered symbols from ES2023 onward; `ws.add('x')` throws a `TypeError`. ## Cycle guards The most common real use is stopping infinite recursion over a possibly cyclic object graph: ```js function walk(value, seen = new WeakSet()) { if (value === null || typeof value !== 'object') return; if (seen.has(value)) return; // already visited on this path seen.add(value); for (const child of Object.values(value)) walk(child, seen); } ``` A `Set` would work here too, because the guard is short-lived, but a `WeakSet` costs nothing extra and cannot outlive the traversal even if someone hoists it to module scope later. The habit is cheap insurance. ## Marking objects you do not own When the group is "objects that have already been processed", the marker must not mutate the object and must not keep it alive: ```js const initialised = new WeakSet(); export function setUp(target) { if (initialised.has(target)) return; // idempotent initialised.add(target); // ... one-time work } ``` The alternative — `target.__initialised = true` — fails on a frozen object, collides with names the owner may add, and leaks into `Object.keys`, spread and serialisation. A `Set` avoids the collision but pins every target for the module's lifetime; `WeakSet` does not. ## Brand checks A factory can record what it produced, so a later function can verify provenance: ```js const brand = new WeakSet(); export function createToken(payload) { const t = Object.freeze({ payload }); brand.add(t); return t; } export function isToken(v) { return typeof v === 'object' && v !== null && brand.has(v); } ``` This is stronger than `instanceof`, which can be fooled by an object whose prototype was set deliberately, and stronger than a marker property, which anyone can copy onto a forgery. Because the set is module-private and not enumerable, only this module can add to it, and a hand-built object can never be a member. ## What you give up The restrictions follow from the weakness, exactly as with `WeakMap`. Entries can be reclaimed at a moment the specification does not define, so exposing a count or an iterator would make garbage-collection timing observable, and the language provides neither: no `size`, no `forEach`, no `values()`, no `Symbol.iterator` — so `[...weakSet]` throws — and no `clear()`; to drop everything, allocate a new set. There is also no data. A `WeakSet` is a membership test only. The moment you want to attach *something* to each object — a count, a timestamp, cached output — you want a `WeakMap`, which does the same weak keying and gives you a value slot. Many codebases skip `WeakSet` entirely for this reason and use `WeakMap` with a trivial value, which is a defensible style choice; `WeakSet` simply states the intent more precisely when there genuinely is no payload. And, as always, members must be objects. "I have already seen this user id" keyed by a string needs a `Set` or `Map` with an eviction rule you write yourself, because primitives have no lifetime for the collector to track. ## Choosing between Set and WeakSet Ask two questions. *Will I ever need to enumerate or count this group?* If yes, you need a `Set` regardless of the leak risk, and must manage removal explicitly. *Do the members outlive the group, or does the group outlive the members?* If the collection is long-lived and its members are transient — nodes, requests, instances — weakness is the difference between a flat heap and a climbing one.