WASM loader does not expose importObject

[jsheard]

WebAssembly modules are able to import foreign Javascript functions and memory objects that are passed in the second parameter of WebAssembly.instantiate(...). Unfortunately the current WASM loader is hard-coded to call instantiate with no import object.

https://github.com/parcel-bundler/parcel/blob/master/src/builtins/loaders/wasm-loader.js
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

The simplest solution would be to have the WASM loader instead run WebAssembly.compile(...) and return the compiled WebAssembly.Module, so the user can call WebAssembly.instantiate(...) with whatever parameters they need. I think that's how Webpacks wasm loader works.

[devongovett]

Yep. I kinda like the way webpack is planning to approach this (I think): imports in WASM files get mapped to module imports the same way imports in JS do. The problem is that the current Rust wasm backend always generates only a single import, and it's always called "env". Ideally it would be possible to specify the name of this import so we could map it to a JS file. Maybe somehow as part of the extern syntax?

For example:

#[wasm_module = "./externs.js"]
extern {
  fn test1();
}

The env name appears to be hardcoded in binaryen which is what Rust uses to do the compilation to wasm. This issue seemed somewhat related: WebAssembly/binaryen#943

cc @linclark @kripken @sokra @TheLarkInn

[linclark]

Yep. I kinda like the way webpack is planning to approach this (I think): imports in WASM files get mapped to module imports the same way imports in JS do.

You're correct, this is the right approach. WASM modules will eventually be ES modules, so imports/exports should work the same as they do in JS. I will likely be championing this over the next few months. Work will be tracked in WebAssembly/design#1087

The problem is that the current Rust wasm backend always generates only a single import, and it's always called "env"

The webpack folks also brought this up. If no one responds with a plan to address this, I'll bring it up in our biweekly WASM toolchain meeting (which is next Tuesday) and see if I can figure out what the plan is.

[kazimuth]

In the shorter term, koute/stdweb#93 would allow rust code using the stdweb library to do the following:

#[no_mangle]
pub fn call_js_function(x: i32) {
    js! {
        var js_function = require("./code.js").js_function;
        js_function( @{x} );
    }
}

The js! macro generates javascript code with rust shims to access it. The javascript code can then be fed to Parcel to resolve imports.

It won't be possible to implement this without access to instantiate, though.

[koute]

I've made an experimental (and really, really hacky) Parcel plugin here to compile Rust to WebAssembly using cargo-web. Compiling through it one can use the js! macro from stdweb to call into the JavaScript from Rust. (And in the next few days I plan to push a js_export! macro which will make it possible to export arbitrary functions from Rust, not just those using WASM-native types.) Unfortunately I had to be somewhat... creative to make that plugin work, since as far as I can see Parcel doesn't allow generating dynamic bundle loaders.

Even if WASM modules will eventually be treated as ES modules it would make sense to support customizing the imports until that future comes (or at least make it possible to do it from a plugin).

[mischnic]

This is also required for emscripten wasm support.

At first I tried to register a custom BundleLoader, but bundle loaders are registered by file extension.

bundler.addBundleLoader('emscripten',require.resolve('./EmscriptenLoader'));

Would it be possible to add an option to specify a bundle loader in an Asset or Packager?

[alexcrichton]

The problem is that the current Rust wasm backend always generates only a single import, and it's always called "env"

@devongovett, @linclark FWIW y'all probably already found this, but on the Rust side of things this is tracked at https://github.com/rust-lang-nursery/rust-wasm/issues/29 where we very much don't want to have anything using env but instead have dedicated syntax like @devongovett mentioned for naming the module.

[vladbat00]

@devongovett, can we expect any progress on this?
Speaking of Rust side, rustwasm/team#29 has been solved

[0xcaff]

Any update on this? I'm not sure how to use rust + wasm-bindgen with parcel and typescript. wasm-bindgen relies on imports being passed to the WebAssembly module. Circumventing the bundler and loading the wasm bundle at runtime doesn't seem possible without writing a parcel plugin to do something about the static files.