add deno target

[jakobhellermann]

adds a new OutputMode for Deno.

Exports and js-imports are generated like OutputMode::Web or OutputMode::Node { experimental_modules: true }.

wasm-files cannot be imported directly, so the file is read at runtime. If embedding the file as a base64 string or similar is preferable, I can try to do that.

[alexcrichton]

Thanks! Dealing with various kinds of import systems can be pretty finnicky and tough to maintain over time. Would it be possible to add a test for this on CI?

[jakobhellermann]

looks like the test finally passes.
I copied the import_js example, because that way imports and exports are being tested, and modified it a little bit to include passing a string to a function.
If anything else should be tested, I can add that.

[alexcrichton]

Nice! I was also wondering, as well, would it be possible to run the full test suite in deno? For example cargo test --test wasm should in theory work for the wasm target. I don't think it exercises any node-specific behavior.

Additionally can you update guide/src/reference/deployment.md with the new deno option?

[jakobhellermann]

I'm not sure what would need to be done to run the test suit in deno.
Add a new file similar to crates/cli/src/bin/wasm-bindgen-test-runner/node.rs for deno and add wasm_bindgen_test_configure!(deno)?

[alexcrichton]

Something like that would work, yeah, although since it's so similar to node it might be best to control with an env var rather than in the code itself. Either way though it's not the most urgent thing in the world. Running the full test suite would provide a lot of confidence that the wrapper generation here is working for all use cases, but since this is a new feature it doesn't have to do everything right out of the gate.

[jakobhellermann]

alright, I tried running the test suite in deno but there seem to be two problems:

1. assert_eq!(export_name, definition_name) fails with Color != Color2. This is because Color is defined in tests/wasm/enum.rs and tests/wasm/node.rs.
   I'm not sure why this isn't asserted for node and what would be the right thing to do here.
2. All the #[wasm_bindgen(module = ...)] attributes only work in node because of some hack with NODE_PATH. I'm not sure what the best approach would be towards removing that hack. Copying every imported file into wbg-tmp?

[jakobhellermann]

also all the tests use exports.foo = ... and require.

[alexcrichton]

Ah ok I think it's fine in that case to go ahead and land this in the meantime. We can perhaps track in an issue what it might look like to run in Deno on CI? Ideally we'd just switch everything to ES imports instead of using the weird hacks that are there today.

It also looks like a wasm file was checked in here too?

[alexcrichton]

All looks great to me, thanks!

[Pauan]

I know this has already been merged, but why does --target web not work?

Why can't you just do await init(Deno.readFileSync("path/to/foo_bg.wasm"));?

[jakobhellermann]

To be honest I didn't quite understand why the init function was needed and thought there were some changes to be done anyway because for Deno the file wouldn't be fetched but Deno.readFileed instead. But I just tried await init(Deno.readFileSync("path/to/foo_bg.wasm")); and it works perfectly...

[jakobhellermann]

maybe wasm-pack can instead have a deno target using --target web which generates a mod.ts with

// @deno-types=foo.d.ts
export * from "./foo.js";
import init from "./foo.js";
init(Deno.readFileSync(import.meta.url logic));

[Pauan]

@jakobhellermann The init function accepts string, Request, Url, ArrayBuffer, Uint8Array, or WebAssembly.Module.

If you pass in an ArrayBuffer, Uint8Array or WebAssembly.Module then it will not fetch. This allows you to handle all of the loading yourself (such as with Deno).

maybe wasm-pack can instead have a deno target using --target web which generates a mod.ts

That won't work, because then you cannot access the exports of the Rust code:

import init, * as exports from "./foo.js";

init(Deno.readFileSync("./foo_bg.wasm")).then(() => {
    // Use exports...
});

Instead, I recommend using our Rollup plugin, which will automatically call init for you. You can customize the loading behavior like this:

rust({
    importHook: function (path) {
        return "Deno.readFileSync(" + JSON.stringify(path) + ")";
    },
})

[alexcrichton]

I think it might still makes sense to have a deno target for "it works similarly to node" where it auto-inits, but perhaps the generated could could be refactored to use top-level await like @Pauan mentions so it's basically --target web but with one extra line?

[Pauan]

@alexcrichton I'm okay with that, though I'm a bit concerned that it might create a precedent for other targets.

[alexcrichton]

It's true yeah I don't want to create a proliferation of too many targets, and @Pauan if you'd like I think it's fine if we revert this and continue discussion on an issue (sorry should have consulted first!)