JSON.stringify is not per spec / mismatches other engines on empty objects when padding is used

[ChALkeR]

e.g.:

print(JSON.stringify([], undefined, 2)) // should be []
print(JSON.stringify({}, undefined, 2)) // should be {}

Spec:

• https://tc39.es/ecma262/multipage/structured-data.html#sec-json.stringify
• https://tc39.es/ecma262/multipage/structured-data.html#sec-serializejsonproperty
• https://tc39.es/ecma262/multipage/structured-data.html#sec-serializejsonarray
• https://tc39.es/ecma262/multipage/structured-data.html#sec-serializejsonobject

25.5.2.6 SerializeJSONArray:

9. If partial is empty, then
   a. Let final be "[]".

This happens regardless of state.[[Gap]] (and state.[[Indent]]) which affects only step 10. "Else".

25.5.2.5 SerializeJSONObject:

9. If partial is empty, then
   a. Let final be "{}".

This also happens regardless of state.[[Gap]] (and state.[[Indent]]) which affects only only step 10. "Else" and elements in step 8 (of which there are none here).

---

I encountered this in snapshot testing with node:test-compatible plain JSON.stringify serialization (as opposed to Jest serializers)

Another place where this could be important is e.g. id generation, if smth does hash(JSON.srtringify(obj)) as a relatively common pattern. If those ids are expected to equal between client and server but aren't, things could break.
That said, that scenario is relatively unlikely to be using padding.

[phoddie]

Very nice. We'll take a look at fixing this. (This appears to be another corner of the spec where test262 coverage is missing.)

[phoddie]

We've got a fix for this in our next release which, fingers crossed, should be available later this week. Note that the problem happened at any level in the hierarchy, not just the root.