@MrBBot I'm trying to use a WASM binary
@MrBBot I'm trying to use a WASM binary with the Miniflare API but running into one major issue. I'm using
esbuild to bundle each worker so I can watch for changes and run 17 workers from a single process. The trouble is esbuild is getting to the './foo.wasm' import first, which is resulting in the CompileError: WebAssembly.instantiate(): Wasm code generation disallowed by embedder (I think that's because the WASM plugin is shoving it into a namespace rather than allowing Miniflare to include it). Do you have any suggestions for how to get around this?5 Replies
I was hoping
external: ['foo.wasm'], loader: { '.wasm': 'text' }, in the esbuild.context call would do the trick, but now I'm getting TypeError: Fetch API cannot load:
Everything works when deployed, so this is definitely an issue with my unique local setup
I think '.wasm': 'file' should work, but I'm getting TypeError: Fetch API cannot load: ../../foo.wasm. Is there something special I need to do to pass the file to the Miniflare API?
Ah, perhaps '.wasm': 'copy'...?
Ahhhhhh okay I think I'm almost there - I can pass the modules directly to modules in the API. That works great for the script (passing the esbuild output as contents), but I'm running into No such module "foo.wasm" imported from "bar" when trying to pass in the WASM. @MrBBot Any tips on how the resolution works for the path there? Or is there an easy way to pass contents? I'm running from node
I tried passing the Uint8Array from the copied wasm from esbuild directly as contents, but run into this guy:
workerd/jsg/util.c++:291: error: e = kj/filesystem.c++:319: failed: expected parts.size() > 0 [0 > 0]; can't use ".." to break out of starting directory
stack: 10f6a4b7a 10f6a3944 10f6a3f06 10defd92b 10e7bc534 10e7878da 10e3823d5 10defe915 10d4f63ea 10d4d8a74 10ced3d6b 10ceda9b4 10cedee8f 10cedd123 10cecc4b6 10cecbff7 10cecbeb4 10cecbe9c 10f6b3a2a 10f6b3e41 10f6b2228 10f6b1f65 10cebb359 /usr/lib/dyld@641e; sentryErrorContext = jsgInternalError
service core:user:images: Uncaught Error: internal error
Victory! I had to use path.resolve to read the WASM file and convert it into a Uint8Array. Passing that as contents does the trick 🏆Unknown User•7mo ago
Message Not Public
Sign In & Join Server To View
I admit I don't know anything about
wasm-bindgen - is it a WASM file itself? If so, what I did here would probably workUnknown User•7mo ago
Message Not Public
Sign In & Join Server To View
Aha! Based on what you just described, yes, I think passing the binary directly to MF like this would be a good approach
I'm actually just straight up trying to use a WASM binary in a worker. I'm using MF instead of the
wrangler CLI because our repo has 17 workers and I'm not about to spin up 17 separate processes, but that means I had to handle getting the binary to MF directly since there's no "magic"