I tried to switch to using --target web (and --target node for node) as @Pauan suggested, but ran into some trouble. My attempt is here but the key points are that:
the use of import.meta in the JS that wasm-bindgen produces with --target web is problematic because:
parcel can't see through that import
babel doesn't yet support this (babel/babel#11364)
if I understand correctly, import.meta can only be used within an ES module which is problematic for the output that parcel produces
Just using the bundler target without any "custom parsing" doesn't work because parcel's built-in wasm loaders (here and here) don't pass in any imports.
By contrast, webpack does the right here which is why its' plugin doesn't need to remap the imports/exports and manually import the wasm blob. This other parcel plugin also uses the bundler target and remaps the imports and exports but then appears to go and replace the default parcel wasm loader with their own version that takes imports as an arg (this plugin effectively does the exact same thing, I think).
It seems like if this plugin were to use --target web and manually substitute the import.meta call for the actual file name of the wasm blob (and then also make it so parcel picks up and serves the blob) things would work. I'm not sure what the best way to do the latter thing is (raw asset? just copy it into the output directory? I know that putting it in generated under the wasm key won't work since, again, the default wasm loader doesn't support imports).
I'm also not sure that the workaround above (assuming it'd work) is actually appreciably better than the current way of doing things (it'd be more resilient to changes in how, for example, enums are exported in wasm-bindgen and that sort of thing but I don't know if it matters). In any case, I'm not very familiar with JavaScript build tooling so I thought I'd write all this out and make sure I'm not completely wrong about the above or missing something.
In the meantime, as the commit says, here's a stopgap that just goes and uses the _bg.js file where it's needed so things work as they did before.
catsigma
commented
4 years ago
I tried to switch to using
--target web(and--target nodefor node) as @Pauan suggested, but ran into some trouble. My attempt is here but the key points are that:import.metain the JS thatwasm-bindgenproduces with--target webis problematic because:parcelcan't see through that importbabeldoesn't yet support this (babel/babel#11364)import.metacan only be used within an ES module which is problematic for the output thatparcelproducesJust using the bundler target without any "custom parsing" doesn't work because
parcel's built-in wasm loaders (here and here) don't pass in any imports.By contrast, webpack does the right here which is why its' plugin doesn't need to remap the imports/exports and manually import the wasm blob. This other parcel plugin also uses the bundler target and remaps the imports and exports but then appears to go and replace the default
parcelwasm loader with their own version that takes imports as an arg (this plugin effectively does the exact same thing, I think).It seems like if this plugin were to use
--target weband manually substitute theimport.metacall for the actual file name of the wasm blob (and then also make it soparcelpicks up and serves the blob) things would work. I'm not sure what the best way to do the latter thing is (raw asset? just copy it into the output directory? I know that putting it ingeneratedunder thewasmkey won't work since, again, the default wasm loader doesn't support imports).I'm also not sure that the workaround above (assuming it'd work) is actually appreciably better than the current way of doing things (it'd be more resilient to changes in how, for example, enums are exported in
wasm-bindgenand that sort of thing but I don't know if it matters). In any case, I'm not very familiar with JavaScript build tooling so I thought I'd write all this out and make sure I'm not completely wrong about the above or missing something.In the meantime, as the commit says, here's a stopgap that just goes and uses the
_bg.jsfile where it's needed so things work as they did before.This closes #30.