Allow custom imports

[FranklinWaller]

Our runtime is half based on WASI with a few custom functions that are specific for blockchains. We use Wasmer-js for the SDK
(And Wasmer-rust for the node). In previous versions of Wasmer-js we could specify extra custom imports (through passing WebAssembly.instantiate(module, customImports);). However in the latest Wasmer-js it doesn't seem like we can pass in custom imports anymore.
Is this something that will eventually? We are looking to upgrade due the WASIX support.

[linear]

SDK-39 Allow custom imports

[Michael-F-Bryan]

This is a limitation of the current wasmer_wasix::WasiEnvBuilder API. We need to update it so you can provide your own custom imports, then add them to the imports object here.

Once that is in place, it should be possible to thread the imports through the wasmer_wasix::runners::WasiRunner, and then add an adapter to the @wasmer/sdk package which lets you use JavaScript functions as the imports.

[Michael-F-Bryan]

It turns out custom imports aren't compatible with the way we do multi-threading.

A big part of the @wasmer/sdk API is how we'll execute WebAssembly modules on a background thread (Web Worker) and give users an Instance handle they can use to communicate with the actual instance (reading stdout/stderr, writing to stdin, waiting for it to exit, etc.). This causes issues with custom imports because the JavaScript values you pass in are tied to the JavaScript VM and can't be accessed from other threads.

I've worked around this in the past by setting up the API so values are passed between threads via postMessage() (see the Scheduler abstraction), but that's just not possible in this scenario because @wasmer/sdk doesn't have control over how the wasmer::Imports object is passed to workers.

Another approach I took in #337 was to create a proxy object which would implement virtual_fs::FileSystem by sending messages to a listener running on the FileSystemDirectoryHandle's original thread.

wasmer-js/src/fs/actors.rs

Lines 44 to 66 in ecbb8e6

	impl<A> Mailbox<A> {
	/// Spawn an actor on the current thread.
	pub(crate) fn spawn(mut actor: A) -> Self
	where
	A: 'static,
	{
	let (sender, mut receiver) = mpsc::channel::<Thunk<A>>(1);
	let original_thread = wasmer::current_thread_id();
	wasm_bindgen_futures::spawn_local(
	async move {
	while let Some(thunk) = receiver.next().await {
	thunk(&mut actor).await;
	}
	}
	.in_current_span(),
	);
	Mailbox {
	original_thread,
	sender,
	}
	}

However, this approach won't work for custom imports because sending messages is an async operation and functions passed to wasmer::Imports need to be synchronous. It also runs into problems when dealing with imports like WebAssembly.Memory or externref because you need the actual WebAssembly.Memory value when instantiating - a proxy or copy isn't good enough.

Unfortunately, I think we'll need to close this issue because it doesn't appear possible within the constraints of our current architecture.

[FranklinWaller]

That's ok, thank you for taking a look @Michael-F-Bryan
Maybe with #370 we can do something similiar and less rely on custom imports and more on something that is also part of WASI(X)

[theduke]

Re-opening because this is still a valid feature request.

[mfcekirdek]

I also need this feature for my use case