René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"No ES6 Map support?","articleBody":"If I run the following test program with msgpack-javascript 2.1.0:\r\n```\r\nimport { encode, decode } from \"@msgpack/msgpack\"\r\nconst map = new Map()\r\nmap.set(\"a\", 1)\r\nmap.set(\"b\", 2)\r\nmap.set(\"c\", 3)\r\nconst encoded = encode(map,{initialBufferSize:128})\r\nconst decoded = decode(encoded)\r\nconsole.log({map, encoded, decoded})\r\n```\r\nThe output is:\r\n\r\n\u003cimg width=\"380\" alt=\"Screen Shot 2020-10-04 at 11 40 42 PM\" src=\"https://user-images.githubusercontent.com/277318/95038024-16f84900-069b-11eb-8f49-30e91fb5d580.png\"\u003e\r\n\r\nConclusion: Asking msgpack-javascript to encode a Map causes it to encode it as if it were an empty object.\r\n\r\nSupporting 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](https://medium.com/intrinsic/javascript-prototype-poisoning-vulnerabilities-in-the-wild-7bc15347c96). 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. ","author":{"url":"https://github.com/mcclure","@type":"Person","name":"mcclure"},"datePublished":"2020-10-05T03:46:04.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/138/msgpack-javascript/issues/138"}