Regression on WASM loading? #1372
gene-ressler
started this conversation in
General
Replies: 1 comment 2 replies
-
|
I think the js generated by emscripten may cause problem for bundlers, they may fail to resolve the url... I am not familiar with js bundlers, will see what @elalish knows about this. Btw, I don't think this is a regression? Was it working before? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi. I'm just starting to integrate Manifold into an existing Angular 20 app. I have seen this thread, which covers essentially the same problem I'm seeing, though with the new Angular build system esbuild+Vite rather than Webpack, for which the problem is apparently fixed.
Fwiw,
manifold.wasmis innode_modules/manifold-3das you'd expect. So I suppose there's something the build process should be doing to position it for Vite? Gemini suggests an elaborate wasm plug-in setup, but I've been burned by AI before.Before I go down the rabbit hole of package configuration munging, has anyone already solved this?
My initial setup code:
and the error stream:
Round 2
I found a hack that works, but won't call it a solution. I added a spec in
package.jsonso thatmanifold.wasmis published as a static asset at URL root. I.e.Then this works for debug builds:
But it would be nice to know how to get
esbuildto put it in the default location.Edit For completeness, the binary doesn't need to go at the URL root. For example:
paired with this will work fine as well:
Round 3
Next problem is distribution builds say
could not resolve resolve "module". This seems to beesbuildtrying to resolve an import that's Node-only. Okay I found a workaround for this, too. Posted it on the other thread.Beta Was this translation helpful? Give feedback.
All reactions