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:

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.