Invalid URL when initiating AssemblyScript generated WASM

I'm writing code in AssemblyScript and compiling it to WASM. AssemblyScript also generates JS bindings that work great in Node, but I'm having trouble getting them working in Cloudflare Workers. In the generated JS bindings, there is code like this this initiates the WebAssembly runtime:
export const {
memory,
your_function,
} = await (async url => instantiate(
await (async () => {
try { return await globalThis.WebAssembly.compileStreaming(globalThis.fetch(url)); }
catch { return globalThis.WebAssembly.compile(await (await import("node:fs/promises")).readFile(url)); }
})(), {
}
))(new URL("release.wasm", import.meta.url));
export const {
memory,
your_function,
} = await (async url => instantiate(
await (async () => {
try { return await globalThis.WebAssembly.compileStreaming(globalThis.fetch(url)); }
catch { return globalThis.WebAssembly.compile(await (await import("node:fs/promises")).readFile(url)); }
})(), {
}
))(new URL("release.wasm", import.meta.url));
Inside my worker, that relative URL does not play nicely: new URL("release.wasm", import.meta.url) generates this error:
TypeError: Invalid URL
at new NodeError (node:internal/errors:399:5)
at new URL (node:internal/url:560:13)
TypeError: Invalid URL
at new NodeError (node:internal/errors:399:5)
at new URL (node:internal/url:560:13)
This works in Node in general. Is there a difference in Cloudflare that makes this not work?
1 Reply
Tin Cap
Tin Cap11mo ago
Gotcha. I'm not surprised by that. I'll have to figure out to run this WASM without the generated bindings then. That's basically what the generated AssemblyScript JS bindings do. I was able to get it to work. AssemblyScript produces raw and esm bindings. The esm bindings were failing as above, but switching to raw bindings worked just fine. The raw bindings are exactly what you suggested, with extra boilerplate stuff to make it nicer to work with. Do you know if I can pull that wasm file out of a node_modules directory? I'm currently copying the wasm file over, but it is published in an npm package. I just tested it and it does indeed work. Super exciting!