Given const o = { m: new Map([['a', 1]]), s: new Set([1, 2]), n: NaN, i: Infinity }, what does JSON.stringify(o) produce — and what changes if you add a BigInt property?

## One rule explains most of it Serialization visits an object's **own enumerable String-keyed properties**. Almost every surprise in this area follows from that sentence plus the fact that JSON's number grammar is finite decimal notation. ## Map and Set collapse to {} ```js JSON.stringify(new Map([['a', 1]])); // '{}' JSON.stringify(new Set([1, 2])); // '{}' ``` The entries of a `Map` and the members of a `Set` live in internal slots that only their own methods can reach. They are not properties, so there is nothing for the algorithm to enumerate. This is the most dangerous item in the list because the failure is completely silent: the code runs, the payload is well-formed, and the data is gone. A cache keyed by `Map` that round-trips through storage comes back empty. The same reasoning explains a related case in the other direction: a typed array *does* have own indexed properties, so `JSON.stringify(new Uint8Array([1, 2]))` gives `'{"0":1,"1":2}'` — an object, not an array, and considerably larger than the bytes it represents. ## NaN, Infinity, and negative zero ```js JSON.stringify({ n: NaN, i: Infinity, j: -Infinity, z: -0 }); // '{"n":null,"i":null,"j":null,"z":0}' ``` JSON's number production is a finite decimal literal with an optional exponent. There is no token for a not-a-number value and none for either infinity, so the algorithm substitutes `null` — the only value in the grammar that means "nothing usable here". Note the asymmetry with `-0`: it *is* finite, so it serializes as the number `0`, and its sign is lost rather than nulled. (`JSON.parse('-0')` does produce negative zero, so the loss happens on the way out, not the way back.) The practical consequence is that a numeric field arriving as `null` is ambiguous. It might mean "absent", or it might mean a computation upstream divided by zero and nobody noticed. ## BigInt throws instead ```js JSON.stringify({ v: 10n }); // TypeError: Do not know how to serialize a BigInt ``` This is the one case in the family that fails loudly, and deliberately so. Writing a big integer as a JSON number would round-trip through the double-precision parser and silently lose the precision that was the entire reason for using it; writing it as a string would silently change the type. Rather than pick, the specification throws and makes you decide. BigInt was added in ES2020, so the throwing behaviour dates from then. The decision is yours to encode: ```js JSON.stringify({ v: 10n }, (key, value) => typeof value === 'bigint' ? value.toString() : value ); // '{"v":"10"}' ``` That is lossless in text, but the consumer now receives a string and must know to convert it back. ## The general fix: an explicit codec pair Every loss above is fixable, and the fix is always the same shape — convert in a replacer on the way out, restore in a reviver on the way in, using a tag the two sides agree on: ```js const replacer = (key, value) => { if (value instanceof Map) return { $type: 'map', v: [...value] }; if (value instanceof Set) return { $type: 'set', v: [...value] }; if (typeof value === 'bigint') return { $type: 'bigint', v: value.toString() }; return value; }; const reviver = (key, value) => { if (value && value.$type === 'map') return new Map(value.v); if (value && value.$type === 'set') return new Set(value.v); if (value && value.$type === 'bigint') return BigInt(value.v); return value; }; const text = JSON.stringify({ m: new Map([['a', 1]]), big: 9007199254740993n }, replacer); JSON.parse(text, reviver).m.get('a'); // 1 ``` The replacer's top-down traversal means the substitute object is itself walked, so nested collections convert too. The reviver's bottom-up traversal means the array under `v` is already finished when the constructor runs. The two orders are complementary by design. A tempting shortcut is to attach a serialization hook to `Map.prototype` so it "just works" everywhere. Resist it: patching a built-in prototype changes behaviour for every library in the process, including ones that rely on the default, and the receiving side still has no idea how to rebuild the value. ## What to take away The format is a text interchange format with six value shapes, not a snapshot of a JavaScript value. Anything richer than those six shapes crosses the boundary only if you encode it deliberately — and the failure mode differs by type: silent emptiness for the collections, `null` for the non-finite numbers, a thrown `TypeError` for arbitrary-precision integers.