Support wasm files in Cloudflare build plugin

[wesbos]

I'm using a package - Shiki - which requires me to import a .wasm file since Cloudflare workers doesn't support inlined WASM binaries.

I've tried using this package: https://github.com/hadeeb/vite-plugin-wasm/ but since there seems to be multiple Vite build steps as part of the Waku build, the file gets put in the dist/public/assets/ directory, and it's not found in the dist/assets directory where it's needed for the server component.

Cloudflare recently added support for wasm files in their own vite plugin. So I am wondering if Waku can also get this functionality, or somehow use the cloudflare vite plugin?

cloudflare/workers-sdk#8031

[dai-shi]

Thanks for reporting. So, this is a Cloudflare-specific issue.

@rmarscher Can you help on this?

[dai-shi]

since there seems to be multiple Vite build steps as part of the Waku build

Yeah, it's the tricky part. This might be mitigated with Vite Environment API in the future, but not sure.
Our workaround for now is unstable_viteConfigs in waku.config.ts, but it may not work for all vite plugins which assume the single vite instance. cc @tylersayshi

[wesbos]

It looks like Cloudflare's own vite config is using the environment API.

Is there a way I can detect which build is running inside a vite plugin? Since I only need mine on the server, maybe just running it on that vite config would fix it

[dai-shi]

Is there a way I can detect which build is running inside a vite plugin?

Yes, for now, we have an unstable API.

import { unstable_getBuildOptions } from 'waku/server';

const phase = unstable_getBuildOptions().unstable_phase;

https://github.com/dai-shi/waku/blob/bfae4eab78e309d555ca1738a0b5df5fd5c3e168/packages/waku/src/server.ts#L73-L96

[wesbos]

great thank you!

[rmarscher]

I use an argon2 wasm file for password hashing but I may have never actually tested it with Waku. I haven't been using password hashing much lately. I'll give a try when I have a moment. I trust that there's probably an issue though.

Let us know if you are able to find a workaround @wesbos. You can probably deploy a separate worker with the functions that need wasm and invoke it from your waku app worker using service bindings. That's a bunch of hoops to jump through but if find yourself fighting with Vite for server-side stuff, then it might be a good route to try. https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/

[wesbos]

Thanks - I guess I could put the renderer in another worker and call it via a service binding.

Though, I'd like to keep everything as "RSC" as possible without making it dependent on Cloudflare.

I was able to switch to the Regex renderer for now, but would like to switch back to the WASM renderer when possible.

[rmarscher]

I'd like to keep everything as "RSC" as possible without making it dependent on Cloudflare.

👍 I'll report back here with my findings.

[rmarscher]

When I tried my hashing function in the dev server, I get this error:

"ESM integration proposal for Wasm" is not supported currently. Use vite-plugin-wasm or other community plugins to handle this. Alternatively, you can use .wasm?init or .wasm?url. See https://vite.dev/guide/features.html#webassembly for more details.

I tried that workaround but I get an error with the dev server:

Error: Failed to parse URL from /src/server/lib/password/argon2-wasi.wasm?init

I also tried building it and running with wrangler dev and that gives a similar error:

✘ [ERROR] TypeError: Invalid URL: /assets/argon2-wasi-Caz-hM6E.wasm?init

      at initWasm

That is a known issue but the workaround uses node:fs and Cloudflare Workers can't access the filesystem.

We can use our Cloudflare Workers static assets binding to fetch from the public assets dir. It's hard to avoid some amount of Cloudflare-specific stuff in your app when deploying there because of the filesystem restrictions.

const c = getHonoContext();
const wasmModule = await c.env.ASSETS.fetch("argon2.wasm");

I have to put this down for a bit and focus on other deadlines that I have... but I'll circle back later. I'm curious if I can get it working with assets fetch.

This won't help people that are using a WASM file that is hidden away in another NPM dependency though - so we should also figure out vite-plugin-wasm. I'll try that too when I get a chance.

[hi-ogawa]

Currently cloudflare's wasm import semantics is a bit unique, so I'd imagine the support for this would require a special setup for now (also assuming their vite plugin is still not general enough for framework usage).

I have shiki wasm example in my rsc demo https://rsc-experiment.hiro18181.workers.dev/test/wasm and made a vite plugin for that purpose https://github.com/hi-ogawa/vite-plugins/tree/main/packages/server-asset#vitepluginwasmmodule. I ported my example to Waku and I think the same idea can work here too. Here is a code with some notes https://github.com/hi-ogawa/reproductions/tree/main/waku-1245-cloudflare-wasm and the deployed app https://waku-1245-cloudflare-wasm.hiro18181.workers.dev/.

One thing I found is that Waku currently moves .wasm assets from rsc build to client build, so I need to patch that part of the code for now to keep .wasm asset accessible for server code:

https://github.com/dai-shi/waku/blob/29af481f1937abc34ef8cdec4a312f5edd5947d7/packages/waku/src/lib/builder/build.ts#L392-L394

[dai-shi]

so I need to patch that part of the code for now to keep .wasm asset accessible for server code:

That makes sense. Would you please send a PR?

[hi-ogawa]

so I need to patch that part of the code for now to keep .wasm asset accessible for server code:

That makes sense. Would you please send a PR?

I think another safer way is to use copyFile instead rename since it's possible that server code wants to let client code fetch wasm via url for other cases. Also probably the same can be said for other assets than .wasm. What do you think @dai-shi?

https://github.com/dai-shi/waku/blob/ec0c41906ae44b6f4ed15faf9d05864e262fa754/packages/waku/src/lib/builder/build.ts#L441-L445

I tested with this patch and the demo is working for me.

[dai-shi]

Yeah, I'm fine with the safer approach (copy instead of rename) for all non-js assets!

[rmarscher]

I found that @cloudflare/vite-plugin includes this plugin to handle wasm: https://github.com/cloudflare/workers-sdk/blob/main/packages/vite-plugin-cloudflare/src/index.ts#L322-L403

It uses emitFile so maybe it works now to add something similar thanks to #1258.

[dai-shi]

Actually, I assumed #1258 solved this issue on the waku end. Can any of you confirm it?

[hi-ogawa]

I think @cloudflare/vite-plugin's wasm support works similarly for build (i.e. emtFile + renderChunk replacement), so that part should be fixed. However, for development, they handle wasm import on miniflare dev runtime side (namely unsafeModuleFallbackService), so to have it working on framework level, probably it's required to integrate cloudflare dev environment all the way. (link to their wasm support PR cloudflare/workers-sdk#8031)

The way my plugin works is that it always uses direct fs access new WebAssembly.Module(fs.readFileSync(...)) during dev assuming it's normal Vite SSR on node. https://github.com/hi-ogawa/vite-plugins/tree/main/packages/server-asset#vitepluginwasmmodule

FYI, for Shiki specifically, now there's an option to use js based engine instead of wasm https://shiki.style/guide/regex-engines#javascript-regexp-engine, so this is probably an easier way out to integrate Shiki on Cloudflare.

[rmarscher]

I tried a bit more and found that it is going to take more work to understand what we can do. I had trouble with some of the community vite wasm plugins. Cloudflare's lack of node:fs is challenging. It can import wasm files though so maybe a dynamic import of the vite-transformed server url could work. I haven't tried it yet.

Even if that does work, it changes the way the wasm needs to be imported which probably isn't going to be possible for people in certain circumstances.

I think using service bindings and a separate worker makes this much easier for running wasm on workers. If wasm is just needed for static rsc builds, the available Vite workarounds should work.

[rmarscher]

It can import wasm files though so maybe a dynamic import of the vite-transformed server url could work.

I should add .wasm to the list of assets that are copied to the Cloudflare Worker dist folder. That list of extensions should probably be customizable. We're exploring custom build adapters as well. https://github.com/dai-shi/waku/blob/main/packages/waku/src/lib/plugins/vite-plugin-deploy-cloudflare.ts#L136