Open tomka opened 3 years ago
After more testing it seems that a workaround (or rather a questionable hack) to "export" the wasm_bindgen
variable from the imported module into the global namespace is to manually add a line like this to the wasm-pack
generated no-modules
.js
file:
self.my_wasm_bindgen = wasm_bindgen;
When this file is imported as a module, my_wasm_bindgen
will be available in the global namespace. It seems that for some reason, self
is the global context within the module, when it is imported. I am not sure why that is, but it fixes my problem for now. It just seems rather fragile and requires a manual extra step.
To use WASM code in a service worker, I am using
wasm-pack
0.9.1 and build my library withwasm-pack build --target no-modules --release
, which generates the respective.wasm
and.js
file. Assuming the path to both files is available in JS asjsPath
andwasmPath
, I try to do the following to dynamically import the wasm library:The
wasmModule
result is not a module but only aSymbol
, hence it can't be used directly. But even though thewasm_bindgen
variable is defined in the.js
file, it is not part of the global namespace (I suppose because it is defined aslet
). It's understandable that this variable is likely available after static imports like in the no-modules wasm-bindgen example, because it will just be defined prior the other code, but how to make thewasm_bindgen
variable available after a dynamic import like the one above?If I build with the
web
target, I can use thewasmModule
an actual module with all its exports. This however doesn't seem to work with service workers where I then get an error about the export syntax in the generated module. Therefore I assume I need to useno-modules
.Thank you for any ideas! I am not sure this is a bug and it could easily be a misunderstanding on my side.