stringify() drops contents of Set and Map

[DmitrySharabin]

Bug

stringify() returns the literal string "{}" for Set and Map values, regardless of their contents.

src/objects.js:270-272:

case "Set":
case "Map":
    return "{}";

Impact

Failing tests that compare these types produce uninformative output. With default deep equality, equals(new Set([1, 2, 3]), new Set([4, 5])) correctly returns false, but the failure message renders both sides as {}. The new formatDiff strategy picker (PR #127) falls back to the "stringified identically but not equal" hint — accurate but unhelpful.

Repro

import { equals } from "htest.dev/check";

export default {
    name: "Set diff",
    run: () => new Set([1, 2, 3]),
    expect: new Set([4, 5]),
    check: equals,
};

Output:

 Actual:   {} (Set)
 Expected: {} (Set)
 (values are stringified identically but not equal)

Fix sketch

Serialize Set and Map by walking their entries — similar to how Array is handled at src/objects.js:273-279.

Once fixed, the format-diff strategies (inline char-diff, multi-line -/+ block) handle these values correctly without further changes.

Related

• PR Strategy-aware diff output for failing tests #127 (strategy-aware diff output) — adds the fallback hint that surfaces this bug
• equals should compare regexps by comparing .source and .flags #48 (RegExp equality fix) — covers the RegExp half of the same case block

[LeaVerou]

Have we considered using Node's util.inspect() instead of reimplementing our own logic?

[DmitrySharabin]

We haven't. As for me, TIL. But it's a nice idea to try.

[DmitrySharabin]

Have we considered using Node's util.inspect() instead of reimplementing our own logic?

Looked into it. node:util is Node-only, so to use util.inspect() in both environments we'd need a browser-compatible inspect impl.

Viable browser path: node-inspect-extracted. 74 KB, zero deps, maintained (latest 3.3.2 on 2026-03-22), ESM, served by jsdelivr + esm.sh. Fits a runtime-import pattern:

const { inspect } = await import(
    IS_NODEJS ? "node:util" : "https://cdn.jsdelivr.net/npm/node-inspect-extracted@3.3.2/index.mjs"
);

Tradeoffs:

Approach	Pros	Cons
util.inspect + browser polyfill	Nested / circular / typed arrays / Symbols / getters for free; battle-tested	74 KB runtime dep; polyfill can lag Node → env divergence; output shape fixed and not ours (Set(3) { 1, 2, 3 } vs Set(3) {1, 2, 3}, different depth-2 truncation, different circular marker); stringify's existing options.custom API doesn't map 1:1 to the util.inspect.custom symbol.
Self-roll Set/Map/RegExp in objects.stringify (the issue's fix sketch)	~15 LOC; no runtime cost; output shape stays ours and under our control; options.custom keeps working as-is	Doesn't generalize — future asks (typed arrays, deep getters, DOM nodes) reopen the question.

My lean: self-roll for this issue. The three affected types are small and children() + join() in objects.js already know how to walk them. Keep node-inspect-extracted in the back pocket as the escape hatch if future issues pile up and we want to swap objects.stringify wholesale.

Happy to go either way — which would you prefer?

[LeaVerou]

In browsers we'd want a different implementation anyway since it can be more interactive.