From feedback by @justjavac :
v8 enabled
--expose_wasm(as well as Node). However, deno seems would just get stuck on the promise returned byWebAssembly.compile, later crashing without warnings
code example(wasm.js):
// @ts-nocheck
const wasm = new Uint8Array(`
00 61 73 6d 01 00 00 00 01 0c 02 60 02 7f 7f 01
7f 60 01 7f 01 7f 03 03 02 00 01 07 10 02 03 61
64 64 00 00 06 73 71 75 61 72 65 00 01 0a 13 02
08 00 20 00 20 01 6a 0f 0b 08 00 20 00 20 00 6c
0f 0b`.trim().split(/[\s\r\n]+/g).map(str => parseInt(str, 16)))
console.log('compile start')
const p = WebAssembly.compile(wasm)
console.log('compile end')
console.log(p)
p.then(module => {
const instance = new WebAssembly.Instance(module)
const { add, square } = instance.exports
console.log('2 + 4 =', add(2, 4))
console.log('3^2 =', square(3))
console.log('(2 + 5)^2 =', square(add(2 + 5)))
}).catch(err => {
console.error(err)
}).finally(() => {
console.log('all done')
})
use node.js:
> node wasm.js
compile start
compile end
Promise { <pending> }
2 + 4 = 6
3^2 = 9
(2 + 5)^2 = 49
all done
use deno:
> deno wasm.js --expose_wasm
compile start
compile end
Promise {}
Yes. It will be easily approachable once https://github.com/denoland/deno/issues/975 (https://github.com/ry/deno/tree/esm) lands. I plan to do this work myself.
In particular I plan to support them as first-class modules, cacheable/loadable from http like other code.
@ry can you say more about what you have in mind for "first-class module" support? Do you mean that you would be able to import them using ESM syntax?
import ? from "https://www.example.com/wasm-example.wasm";
Or would it match something closer to web & node's current support, where you need to fetch/read the file and then instantiating it manually?
I believe the actual problem is that WebAssembly.compile() would return an uncontrolled promise that is not registered to the event loop as a task. While Liftoff is still compiling the module, the event loop would see that there is no pending task and simply exit...
We might need to take care of this if we are planning to refactor the event loop some time
Actually it seems that there is actually no attempt to compile the module, or that the attempt is never even present in the microtask queue (an infinite loop of RunMicrotasks() calls on Isolate with kExplicit Microtask policy still yields nothing)... Not sure what I'm missing here
An experimental branch of Node has started with the import "./foo.wasm"; implementation: https://github.com/nodejs/ecmascript-modules/pull/46
Also see https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration about the current standardization process
Resolved by #1677
@kitsonk actually not yet, WebAssembly.compile still exits immediately...
The title of the issue is a bit mis-leading, I think we are talking about support WebAssembly as modules? Either way, it isn't clear to me what we need to do here beyond what was delivered in #1677 except supporting .wasm. Is it the scheduling of the WebAssembly.compile() promise not being actually done async, in addition to the ability to load .wasm modules directly? Right now you can compile and run WebAssembly code in Deno, right?
It'd be great to have a working documented example like this for deno: https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm
Anything about WASI?
https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md
With https://github.com/denoland/deno/pull/2548 landed, I think WASM works in Deno as it does in browsers.
There is much more we want to do with respect to wasm, but I think it should be handled in more specialized issues like https://github.com/denoland/deno/issues/2552
Most helpful comment
Yes. It will be easily approachable once https://github.com/denoland/deno/issues/975 (https://github.com/ry/deno/tree/esm) lands. I plan to do this work myself.
In particular I plan to support them as first-class modules, cacheable/loadable from http like other code.