msgpack-javascript icon indicating copy to clipboard operation
msgpack-javascript copied to clipboard

No ES6 Map support?

Open mcclure opened this issue 4 years ago • 3 comments

If I run the following test program with msgpack-javascript 2.1.0:

import { encode, decode } from "@msgpack/msgpack"
const map = new Map()
map.set("a", 1)
map.set("b", 2)
map.set("c", 3)
const encoded = encode(map,{initialBufferSize:128})
const decoded = decode(encoded)
console.log({map, encoded, decoded})

The output is:

Screen Shot 2020-10-04 at 11 40 42 PM

Conclusion: Asking msgpack-javascript to encode a Map causes it to encode it as if it were an empty object.

Supporting Maps in some capacity would be good because if anything it is better to store Maps in msgpack than to store objects. Sometimes deserializing in JavaScript can cause problems or even security flaws if keys overwrite "special" javascript objects like hasOwnProperty or __proto__. Here is an example of such a problem. I suspect msgpack-javascript itself will not have any such security flaws, but it is easy for client code to have such security flaws and the security issues can be sidestepped by using Maps instead of objects.

mcclure avatar Oct 05 '20 03:10 mcclure

Thank you for your report.

This is the specification and won't be fixed because MessagePack is designed to communicate in multi-languages. I won't add any flavors by default.

However, any JavaScript programs use lots of non-primitive objects, so the MessagePack spec has extensions. See extension types for details.

Also, I'd like to add extensions to handle non-primitive objects like ES2015's Map, just like as browsers do.

gfx avatar Oct 05 '20 04:10 gfx

Sorry, where in the spec does it say something incompatible with Maps? As far as I can tell, the spec actually places no restriction on map keys, so the current implementation seems to be non-compliant, and the only way to make it compliant is to decode into Maps instead of plain objects.

joshyrobot avatar Jun 11 '21 08:06 joshyrobot

To concur with what @joshyrobot is saying, what we're looking for is not so much a way to encode maps in addition to objects, we're looking for a way to encode maps instead of objects— something like an alternate mode in which maps are always created and consumed and vanilla javascript objects are never created or consumed.

mcclure avatar Jun 12 '21 20:06 mcclure