fix: bundled wasm assets not found during build #681
Conversation
🦋 Changeset detectedLatest commit: 8849e15 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
🧪 Prereleases are available for testing 🧪 @cloudflare/next-on-pagesYou can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/next-on-pages/runs/8116471634/npm-package-next-on-pages-681@cloudflare/eslint-plugin-next-on-pagesYou can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/next-on-pages/runs/8116471634/npm-package-eslint-plugin-next-on-pages-681 |
|
I've given this a test on my system, and it works! 🙌 |
|
Thanks, wasm imports work as expected now. |
There was a problem hiding this comment.
Thanks a lot @james-elicx
I've seen this issue popup here and there and hadn't had the time to tackle it, thanks so much for having a look 🙏
But I am a bit hesitant on the changes for two reasons, one is the --skip-build flag issue I mentioned in my comment (should be an easy fix anyways) the other is that I am not sure if changing any file outside .vercel/static/output is appropriate...
I might be wrong but I think we don't do this anywhere else and try to keep things in memory instead whenever possible (to avoid issues like the one I mentioned in which using the skip build option can make the build no longer idempotent)
what do you think?
| } | ||
|
|
||
| await mkdir(dirname(newAssetPath), { recursive: true }); | ||
| await symlink(currentAssetPath, newAssetPath, 'file'); |
There was a problem hiding this comment.
I think this breaks when using the -s|--skip-build flag:
There was a problem hiding this comment.
ah good catch, adding a check to only do it when there is no file there.
this is true. i dont think we do this anywhere else in the .vercel/output/functions. on the one hand, this make the fix a lot simpler, instead of changing how some of the deeper logic works, as it allows all the logic we have for the assets in a function's dir to continue doing their thing instead. would you prefer i make the change to the deeper parts where it's processed instead of symlinking them? |
yeah I think I'd much rather prefer that if it's not too much of a thing to ask 😓 I feel like if we start to "cheat" things can go out of hand and spiral out of control, saying "we never touch files that don't belong to us" feels like a much cleaner/clearer mental model that can prevent pain in the long run (and again, I think that adding exceptions to this can lead to unpredicability and pain 😓) I don't think that not using symlinks is going to be problematic... it might a bit cumbersome as the paths need to be passed around though 😓 Would you be willing to give that a shot? 🙏 |
There ya go. You were right, should have done it like this originally, good shout :) Sorry for the delay! |
|
Thank you all for the fix! 🙂 |
This PR does the following:
filePathMapoption in a function config file.fixes #676
fixes #672
Example of this in a function's
.vc-config.json: