Consider shipping wasm files to npm

[TzviPM]

I'm trying to use hash-wasm's argon2 implementation with Vercel's Edge runtime and running into an compilation error. It seems hash-wasm's dist files include a hard-coded string of the wasm base64-encoded and then run through WebAssembly.compile. Dynamic code evaluation isn't supported in that runtime (https://nextjs.org/docs/messages/edge-dynamic-code-evaluation).

Wasm files can be imported differently and handled by nextjs during bundling (ex. import someWasm from './some.wasm?module') but the wasm outputs from hash-wasm don't seem to be shipped as independant artifacts with the library code.

I imagine having access to the wasm files could be useful for other situations as well.

Would you be open to a PR to add this?

[Daninet]

Implementing alternative ways of loading binaries would increase the complexity of the library and I want to avoid that.
Cloudflare and Vercel requires a non-standard way of loading WASM binaries. At this moment I consider it something that needs to be fixed on their side by allowing all standardized ECMAScript / WASM APIs to work properly.

[ComicScrip]

If anyone really needs it and can't wait for Vercel and CF to change their ways, I've just made a (little hacky) fork that is runnable on Vercel Edge and CF Workers. 😄

[dynst]

hash-wasm/lib/WASMInterface.ts

Lines 98 to 103 in 373b796

	if (!wasmModuleCache.has(binary.name)) {
	const asm = decodeBase64(binary.data);
	const promise = WebAssembly.compile(asm);
	wasmModuleCache.set(binary.name, promise);
	}

Can you replace WebAssembly.compile() from base64-decoded wasm with WebAssembly.compileStreaming() from a separate binary file?

It's been supported since Node.js 18.1 implemented the standard WebAssembly Web API. Node 16 has been EOL since late 2023.

https://nodejs.org/en/blog/release/v18.1.0

nodejs/node#42701

https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript_interface/compileStreaming_static#browser_compatibility

[Daninet]

The main goal of this library is to be portable and easy to use. So I want to avoid doing that because having separate wasm binaries would make it harder to use without tweaking the build configuration in some bundlers like Webpack.

[dynst]

But what problem are you solving exactly? Is there an old issue about it?

Do those problems even still exist in modern bundler versions?

[Daninet]

I think the problem still exists in the latest Webpack. You need to manually add a .wasm loader to the webpack config or enable experimental features: https://chatgpt.com/s/t_687fd44577e48191a7ef010603750479

Why do you want to use compileStreaming() from node.js? What would be the advantage of it when these wasm binaries are just a few kilobytes and compiled instantly?

[dynst]

https://grok.com/share/c2hhcmQtMw%3D%3D_2a0b7545-c912-44de-ae41-044335b13520

https://bundlephobia.com/package/hash-wasm@4.12.0

The added overhead of base64-encoding WebAssembly as a string didn't seem to be giving any real benefits, but maybe I was mistaken. Webpack does seem to allow binary assets out of the box with no configuration, just with particular file extensions.

[floratmin]

It works with cloudflare pages and wrangler v4.30.0