Importing a Wasm program

[xtuc]

This came up in the nodejs PR (nodejs/node#27850), there are some concerns about import a WebAssembly Module that is a program.

We might want to:

• only import some exported symboles and avoiding calling the main function.
• calling the main function in a safe way; seperated memory, forked from the main process.

We don't provide any solution for this, apart from transforming the module AOT because it's part of the spec semantics.

[xtuc]

Thinking about this more, @guybedford I think that already in JavaScript a library can spawn an interface on top of your app, with not much control.

If we want control over the process the JavaScript module syntax might not be suited. Which is similar to js.

I believe it's more a toolchain convention issue because they could explicitly export main function and import/export the memory.

[guybedford]

The current directions seem to be to have WASI modules export the memory and have the "main" run on import, but my concern is that while this makes complete sense as a technical model, we need to ensure that this model is well-suited to how toolchains can be expected to be used and integrated with the ES module system.

I understand that toolchains are still somewhat in flux here too, but then we shouldn't rush the runtime semantics likewise.

[tschneidereit]

The current directions seem to be to have WASI modules export the memory

That'll certainly not be the case in the long run: exporting the memory by default is a clear break of encapsulation that a module would need to explicitly opt in to. Whether the main function is run or not will also differ between modules—this touches on the Commands and Reactors patterns @sunfishcode described and recently provided an experimental implementation of.

[guybedford]

@tschneidereit thanks so much for those links. Having runtimes being able to distinguish memory handling as well as Command or Reactor WASI modules, and handling the initialization appropriately sounds very sensible.

My primary concern here though is whether or not the ESM integration of WASM for a Command should run the "main" on import, as I don't want us to be in a position where a lot of useful WASI code written as Command / programs requires custom Node.js processes or VM initializations to run together within a larger application.

[devsnek]

given that i can import a source text assumed to be an entry point (e.g. something like import 'bin/run.mjs'), why would we make an exception for wasi? additionally in a runtime using esm, it would be odd to have an exception where processing the entry point is sometimes not done via the esm loader. (mytool file.mjs vs mytool file.wasm where file.wasm is a wasi command)

[guybedford]

Node.js has set up a fork for WASI development in https://github.com/nodejs/wasi/.

This fork is open to collaboration and PRs, which may be a useful incubator for ESM integration proposals related to WASI, providing a path for allowing experimentation that can move to upstreaming into Node.js core under experimental flags and finally as stable.

[guybedford]

This problem has since been solved by the source phase imports proopsal. In addition in the WebAssembly instance integration, we now have wasm: and wasm-js: schemes reserved on imports and exports so can in theory add additional contracts in future to smooth integration. The recommendation remains to use source phase imports though for these kinds of cases.