How does the direct_imports facility work?

[jrandall]

Summary

I see in 0.2.45 there is a direct_imports Map that is used to populate the WebAssembly imports object when the Module is instantiated (I noticed it was added for the "web" deployment target in #1503).

I cannot find any example of how to use this feature, but I need to be able to add a custom import (I currently compile using the "web" deployment target and then manually edit the init function after every build to add an extra module to the imports object). How can I add a custom import using this facility?

Additional Details

What I'm actually trying to do is to use wasm-bindgen to build a javascript interface for a WASI C library. I have been successful at doing this by linking the C library into my wasm-bindgen project as an FFI, but the resulting *_bg.wasm target ends up with a dependency on symbols in the wasi_unstable namespace. In the browser, I provide these by manually adding 'wasi_unstable': WASIPolyfill to the imports object created in the init function, but I would like to be able to configure wasm-bindgen so that it does this for me.

I also have not been able to figure out how to get the "bundler" deployment to work with this at all, but I would be hopeful that a proper solution in which I tell wasm-bindgen what extra imports are needed might make the (webpack-based) "bundler" deployment work as well.

Any advice or pointers to docs I may have missed would be appreciated!

[alexcrichton]

Thanks for the question! This isn't actually a user-facing feature it's something that's internally tracked and detected. It's since been replaced by a different mechanism of tracking this, and it's basically just an internal optimization for binding imports to the wasm module.

For WASI I'd probably recommend not using the wasm-bindgen toolchain for now. It's probably best to stick with the raw native wasi toolchain (e.g. the wasm32-wasi target). While it's possible to work with wasm-bindgen it'll probably require a lot of manual intervention and it definitely won't be an out-of-the-box experience like wasm-bindgen largely is today without wasi.

[jrandall]

The reason I want to use wasm-bindgen for the client bindings is because I want to provide javascript with an interface that returns promises (backed by wasm-bindgen-futures) and I didn't think there was an equivalent functionality using the wasm32-wasi arch target.

After patching the generate wasm-bindgen js bindings to import the WASIPolyfill as wasi_unstable, everything does seem to work so far. To be clear, I am building using the wasm32-unknown-unknown arch target for these bindings, it's just that I link in an FFI library that has WASI modules compiled in.

Would there be scope to add a generic (not WASI-specific) mechanism for wasm-bindgen to provide additional imports to the WASM instantiation? I'm happy to try to help implement it, but I'm not sure where it best fits (and also I noticed that this part of the code seems to be in flux because of changes related to WebIDL support?).

[alexcrichton]

I think that'd definitely be in scope yeah! We don't have a great story for that today but I think it'd be cool to be able to have a wasm file which imports from modules that wasm-bindgen doesn't know about but it's still configured in the generated bindings one way or another.