This PR adds an option, preferMap, which when set causes all MessagePack maps to be decoded to javascript Maps.
The preexisting default behavior is to decode as Map if non-string keys exist and as a plain object otherwise. This means that decode(encode(new Map()) is {}, i.e., Maps do not round-trip reliably. It also prevents the user from reliably determining the order of entries in the encoded MessagePack map. (It's not clear to me if MessagePack intends users to care about map order, but the spec doesn't appear to prohibit it.) An example:
This PR adds an option,
preferMap
, which when set causes all MessagePack maps to be decoded to javascriptMap
s.The preexisting default behavior is to decode as
Map
if non-string keys exist and as a plain object otherwise. This means thatdecode(encode(new Map())
is{}
, i.e.,Map
s do not round-trip reliably. It also prevents the user from reliably determining the order of entries in the encoded MessagePack map. (It's not clear to me if MessagePack intends users to care about map order, but the spec doesn't appear to prohibit it.) An example:The
Map
's order is reflected by the encoded data but replaced by js object traversal order in the decoded data.With
preferMap: true
,decode(encode(new Map())
isnew Map()
, and the example above decodes to aMap
with key ordering'b', '1', '01', '0', 'a'
.