I've been thinking that exporting the library directly to wasm could be a mistake. Actually, it makes sense having an adapter between the raw library and the wasm-pack, considering its usage or the user interaction with wasm.
Keep in mind that cross-calling between JS and the WASM world is quite expensive at the moment. It's something you want to minimize, and it doesn't seem that writing a glue layer on top of the WASM code will be parsimonious w.r.t. such cross-calls.
W is M implementation in wasm. J is M implementation in javascript.
A is the cost of W called k times under wasm environment. B is the cost of W called k times under javascript environment including the interfacing cost. C is the cost of J called k times under javascript environment.
So, if k is small and M is evaluated under large n (a large input size), A<B<C.
We may even say that B->A⁺ and still B<<C (B much lesser than C).
It is desirable to have W if possible.
On the other hand, if k is high and M is evaluated under small n, B->A⁺ is false.
Instead B-A increases, C-B decreases. Eventually, C<B, due to the interfacing cost.
In this point W would make no sense if J is possible.
A < C holds no matter what, but for small n and small k, C->A⁺.
And when you say "quite expensive at the moment", you mean A<B<C to eventually hold forever?
I don't honestly know, but what just might be possible is A<≈B<C at some point. That is, that running a wasm module in a purely wasm environment vs running that wasm module in a browser might not matter much in terms of real-world performance.
But the only ones that might be able to answer that definitely are the people implementing the WASM standards.