Could be made more treeshakeable

[AllNamesRTaken]

MsgPackr is fast but when you only need a part of it, its doesn't treeshake very well,
exporting and minifying only encode() yields a file size of about 21 KB while as a comparison the same with @msgpack/msgpack yields a file size of about 10Kb.

I believe this stems from msgpackr's architecture where the Unpackr object is the base object also for unpack functionality and on top of that the Packr object declares most of its functions as private functions inside its constructor through functions scoped variables.

A possible step that might also be easier for the V8 to optimize would be to go with a cleaner more functional approach. Just make all functions take a well defined context object (to avoid poly/ megamorphism) Then there can be some global state objects like the defaults and also some classes to instanciate which then uses these functions if that is what you want.

I believe this would make it much more treeshakeable / modular and possibly faster (but the V8 us magic so you never know).

[kriszyp]

Out of curiosity, what it is the use case for minimizing to just the encoder? I designed this with the expectation that generally if you want a minimal single module, it would be for decoding messages in the browser.

A possible step that might also be easier for the V8 to optimize would be to go with a cleaner more functional approach.

Generally, differences approaches tend a look a lot cleaner from a distant. But I think the real issue is the public API itself is designed such that new Packr() provides an instance with full decode/encode functionality as well as the benefit of single configuration that can be used for both. And I intend to maintain backwards compatibility for the API.

I think perhaps are more feasible approach might be to have a pack-only.js module that is generated from pack.js, but with the imports from unpack.js replaced with no-ops. You could then import something like msgpackr/pack-only.js to have an encode-only msgpackr module. Would that be a reasonable solution for your use case?

[AllNamesRTaken]

Hi,
Well it is a niche use but use it to get large structured data out of Clearscript V8 into .net. Basic types and typed arrays can be gotten with only a single marshal across the V8 boundary while other structures require one marshal per data point. For large data this kills performance. And JSON serialisation deserialisation is too slow. Message pack solves this.

But this should be no different than passing data from any api to another. Msgpackr is fast. :). But since i have to create a new v8 engine and reparse the scripts on each call, parse size becomes a virtue.

[AllNamesRTaken]

My thought was to break the Unpackr out into a separate module sucj as Ctx and then let Unpackr be Ctx plus the different pure functions with the Ctx bound as needed. Then pack and unpack would be trivial to expose as separate modules implementing the corresponding functions with default state bound.

But i understand that it might be out of scope. If i get time i might give it a shot. Also imo typescript would be pretty sweet.