-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support wasm in SSR #8882
Comments
If anyone finds this issue and needs a quick fix, we've created a vite plugin to use your WASM packages as regular ES modules that also supports SSR. Only supports wasm-pack generated modules at the moment. |
I found this issue because I was trying to understand a regression I found that's blocking me updating from Vite 4.5.0 to Vite 5.2.11. I have a WASM library I built as an ES module with Emscripten, so I have In Vite 4 this was working just fine both in the browser and in my node-based testing with
So even though Also, the Vite docs seem to say a lot about needing plugins for loading WASM, but I'm not using any plugins with Vite 4. Has functionality been removed from core? |
@elalish from the error message, it looks like you're referring to Vitest with |
Ah, correct you are! Okay, Vite 5.2.11 is working fine - it must have been the Vitest update that did it. I'll report over there instead - had sort of thought that was all part of the same project. |
Done: vitest-dev/vitest#5704 |
Description
Currently, the wasm plugin usually get the
.wasm
file usingfetch
. This approach doesn't work in SSR. Even iffetch
were available, fetching a relative path would not work. This results in errors such asERR_INVALID_URL
when in SSR.Suggested solution
By adding an extra if cause to the wasm helper, we could check the
import.meta.env.SSR
to see if we're in SSR mode. If we are, then we could load the file from disk instead of fetching it over the network. Something like this:However, there might be problems to using
import.meta
that I'm not aware of. It seems to work fine for me when I'm testing it, but I've only tested it with SvelteKit.If using the SSR environment variable isn't an option, then we could of course use some
typeof window === "undefined"
or perhapsprocess
would be better. But there might be several pitfalls with that, mainly other plugins that polyfills window, process or whatever thing we might use. Perhaps a better approach would be to add the file system logic in a.catch
block on thefetch
itself, something like:Another problem with loading from disk is that the URL provided is a URL, and not a file path. Fortunately it contains the file path, but I'm not sure if that would always be the case, or if it might be a better way of resolving the file path. Using the provided
url
string, it is possible to decode the path using something likeurl.replace("/@fs", "")
.Alternative
A workaround is to use another wasm plugin. I haven't found a vite wasm plugin that works with SSR, so currently we have created our own just to make it work (using the
import.meta.env.SSR
technique mentioned above). That works great with SvelteKit, but might not work with everything. If it's of any interest to someone else, just let me know and I can see if we could push it to NPM.I've also raised an issue (Menci/vite-plugin-wasm#4) in the vite-pugin-wasm repo to make SSR work, but it has some challenges regarding ESM to utilize
import.meta
.Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: