Option to specify extra javascript imports required when instantiating WASM Module #1584
Comments
|
To clarify, I believe you are talking about the import object which is passed to So you want something like this: WebAssembly.instantiate(buffer, {
"./rustc_h_gnju0uqy2i9": __exports,
"wasi_unstable": WASIPolyfill
})Correct? |
|
Thanks for the report @jrandall! Assuming @Pauan's interepretation is correct (which also matches my reading here) I'm not certain how the best way to handle this would be. I like the idea of specifying something in the Rust source code in that presumably when you're importing something you know what you want to import, and when someone imports you they may not know what you wanted to import. For something like An alternative possibility which goes against putting it in the source would be something like: import init from './the.js';
init({wasi_unstable: WASIPolyfill});(or something like that where it's passed to the I think though we'd probably want to shoot for something that ideally works in all output modes. It may be the case though that |
|
Sorry to have not noticed earlier updates and questions on this issue until now. The above interpretation by @Pauan is correct, and yes, I would note that I do have this all working using The patch file I apply to the js bindings built by wasm-bindgen is: The latter part of the patch is a workaround to the other issue (#1576) required for WASI support, which is that we need to be able to get the |
Support was previously (re-)added in rustwasm#1654 for importing direct JS values into a WebAssembly module by completely skipping JS shim generation. This commit takes that PR one step further by *also* embedding a direct import in the wasm file, where supported. The wasm file currently largely just imports from the JS shim file that we generate, but this allows it to directly improt from ES modules where supported and where possible. Note that like rustwasm#1654 this only happens when the function signature doesn't actually require any conversions to happen in JS (such as handling closures). For imports from ES modules, local snippets, or inline JS they'll all have their import directives directly embedded into the final WebAssembly binary without any shims necessary to hook it all up. For imports from the global namespace or possibly vendor-prefixed items these still unconditionally require an import shim to be generated because there's no way to describe that import in an ES-friendly way (yet). There's a few consequences of this commit which are also worth noting: * The logic in `wasm-bindgen` where it gracefully handles (to some degree) not-defined items now only is guaranteed to be applied to the global namespace. If you import from a module, it'll be an instantiation time error rather than today's runtime error when the import is called. * Handling imports in the wasm module not registered with `#[wasm_bindgen]` has become more strict. Previously these imports were basically ignored, leaving them up for interpretation depending on the output format. The changes for each output target are: * `bundler` - not much has changed here. Previously these ignored imports would have been treated as ES module imports, and after this commit there might just be some more of these imports for bundlers to resolve. * `web` - previously the ignored imports would likely cause instantiation failures because the import object never actually included a binding for other imports. After this commit though the JS glue which instantiates the module now interprets all unrecognized wasm module imports as ES module imports, emitting an `import` directive. This matches what we want for the direct import functionality, and is also largely what we want for modules in general. * `nodejs` - previously ignored imports were handled in the translation shim for Node to generate `require` statements, so they were actually "correctly handled" sort of with module imports. The handling of this hasn't changed, and reflects what we want for direct imports of values where loading a wasm module in Node ends up translating the module field of each import to a `require`. * `no-modules` - this is very similar to the `web` target where previously this didn't really work one way or the other because we'd never fill in more fields of the import object when instantiating the module. After this PR though this is a hard-error to have unrecognized imports from `#[wasm_bindgen]` with the `no-modules` output type, because we don't know how to handle the imports. Note that this touches on rustwasm#1584 and will likely break the current use case being mentioned there. I think though that this tightening up of how we handle imports is what we'll want in the long run where everything is interpreted as modules, and we'll need to figure out best how wasi fits into this. This commit is unlikely to have any real major immediate effects. The goal here is to continue to inch us towards a world where there's less and less JS glue necessary and `wasm-bindgen` is just a polyfill for web standards that otherwise all already exist. Also note that there's no explicitly added tests for this since this is largely just a refactoring of an internal implementation detail of `wasm-bindgen`, but the main `wasm` test suite has many instances of this path being taken, for example having imports like: (import "tests/wasm/duplicates_a.js" "foo" (func $__wbg_foo_969c253238f136f0 (type 1))) (import "tests/wasm/duplicates_b.js" "foo" (func $__wbg_foo_027958cb2e320a94 (type 0))) (import "./snippets/wasm-bindgen-3dff2bc911f0a20c/inline0.js" "trivial" (func $__wbg_trivial_75e27c84882af23b (type 1))) (import "./snippets/wasm-bindgen-3dff2bc911f0a20c/inline0.js" "incoming_bool" (func $__wbg_incomingbool_0f2d9f55f73a256f (type 0)))
Support was previously (re-)added in rustwasm#1654 for importing direct JS values into a WebAssembly module by completely skipping JS shim generation. This commit takes that PR one step further by *also* embedding a direct import in the wasm file, where supported. The wasm file currently largely just imports from the JS shim file that we generate, but this allows it to directly improt from ES modules where supported and where possible. Note that like rustwasm#1654 this only happens when the function signature doesn't actually require any conversions to happen in JS (such as handling closures). For imports from ES modules, local snippets, or inline JS they'll all have their import directives directly embedded into the final WebAssembly binary without any shims necessary to hook it all up. For imports from the global namespace or possibly vendor-prefixed items these still unconditionally require an import shim to be generated because there's no way to describe that import in an ES-friendly way (yet). There's a few consequences of this commit which are also worth noting: * The logic in `wasm-bindgen` where it gracefully handles (to some degree) not-defined items now only is guaranteed to be applied to the global namespace. If you import from a module, it'll be an instantiation time error rather than today's runtime error when the import is called. * Handling imports in the wasm module not registered with `#[wasm_bindgen]` has become more strict. Previously these imports were basically ignored, leaving them up for interpretation depending on the output format. The changes for each output target are: * `bundler` - not much has changed here. Previously these ignored imports would have been treated as ES module imports, and after this commit there might just be some more of these imports for bundlers to resolve. * `web` - previously the ignored imports would likely cause instantiation failures because the import object never actually included a binding for other imports. After this commit though the JS glue which instantiates the module now interprets all unrecognized wasm module imports as ES module imports, emitting an `import` directive. This matches what we want for the direct import functionality, and is also largely what we want for modules in general. * `nodejs` - previously ignored imports were handled in the translation shim for Node to generate `require` statements, so they were actually "correctly handled" sort of with module imports. The handling of this hasn't changed, and reflects what we want for direct imports of values where loading a wasm module in Node ends up translating the module field of each import to a `require`. * `no-modules` - this is very similar to the `web` target where previously this didn't really work one way or the other because we'd never fill in more fields of the import object when instantiating the module. After this PR though this is a hard-error to have unrecognized imports from `#[wasm_bindgen]` with the `no-modules` output type, because we don't know how to handle the imports. Note that this touches on rustwasm#1584 and will likely break the current use case being mentioned there. I think though that this tightening up of how we handle imports is what we'll want in the long run where everything is interpreted as modules, and we'll need to figure out best how wasi fits into this. This commit is unlikely to have any real major immediate effects. The goal here is to continue to inch us towards a world where there's less and less JS glue necessary and `wasm-bindgen` is just a polyfill for web standards that otherwise all already exist. Also note that there's no explicitly added tests for this since this is largely just a refactoring of an internal implementation detail of `wasm-bindgen`, but the main `wasm` test suite has many instances of this path being taken, for example having imports like: (import "tests/wasm/duplicates_a.js" "foo" (func $__wbg_foo_969c253238f136f0 (type 1))) (import "tests/wasm/duplicates_b.js" "foo" (func $__wbg_foo_027958cb2e320a94 (type 0))) (import "./snippets/wasm-bindgen-3dff2bc911f0a20c/inline0.js" "trivial" (func $__wbg_trivial_75e27c84882af23b (type 1))) (import "./snippets/wasm-bindgen-3dff2bc911f0a20c/inline0.js" "incoming_bool" (func $__wbg_incomingbool_0f2d9f55f73a256f (type 0)))
|
FWIW I've posted #1689 which tightens up some of the handling of unknown import directives to wasm-bindgen (including wasi ones). I think for now this will need to continue be handled with patch (although perhaps in a slightly different way) or with bundler mappings in theory. As the name impiles the wasi module story is still in development, so I'm not sure we'll want to set too much in stone just yet. |
Motivation
The
initfunction generated by wasm-bindgen adds an import bindings it generates, but there does not currently appear to be any way to specify additional imports that the WASM module may require. My immediate use case is to be able to provide a'wasi_unstable': WASIPolyfillimport in order to support a WASI library to which my wasm-bindgen project links, but this general facility could be used whenever a WASM module needs direct access to javascript in the browser that doesn't go through wasm-bindgen (i.e. it should make it easier for wasm-bindgen to interoperate with other mechanisms for binding between WASM and javascript).Proposed Solution
I am not sure where is the best place would be to implement this option. The import needs to run before the wasm module is loaded, so it seems like it ought to be pure javascript, so it doesn't really make sense to annotate any rust code with the #[wasm_bindgen] macro to configure it.
For this reason it seems like the best option might be to have a crate level setting that just defines all extra imports as a javascript fragment that just gets dumped into the generated init function. However, there don't appear to be any other aspects of #[wasm_bindgen] that work that way, so I'm not sure exactly what to suggest.
Alternatives
Despite it being perhaps a bit awkward, perhaps It could be configured from the #[wasm_bindgen] macro using a self-contained annotation that would functions similar to an inline_js that indicates that it generates an import binding (can the macro annotate an empty code block or something like that?).
Perhaps something like:
or
The text was updated successfully, but these errors were encountered: