Support transforming import source for wasm

[nicolo-ribaudo]

Q	A
Fixed Issues?
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?	Yes
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This proposal is stage 3, and (at least for Wasm modules) we can compile it to WebAssembly.compileStreaming + fetch in the browser and WebAssembly.compile + readFile in Node.js. Wasm are the only modules for which there is currently a source import, so this is a safe limitation.

While working on this PR I learned that Node.js does not support fetching from file:// URLs, and that increases the complexity of the transform, based on the targets:

• for browsers and Deno we use await WebAssembly.compileStreaming(fetch(...))
• for Node.js in import statements we use new WebAssembly.Module(fs.readFileSync(...)) (which does not introduce TLA in the module, so it's more compliant to the spec)
• for Node.js in dynamic import we use await WebAssembly.compile(await fs.promises.readFile(...))

In addition to that, we should use import.meta.resolve but we need a fallback for old environments where it's not supported.

This plugin does not work everywhere, for example when bundling to webpack you need to transform import source x from "x" to import raw from "!!raw-loader!./x.wasm";; const x = WebAssembly.compile(raw);. However, other cases can be handled by community plugins.

cc @lucacasonato @guybedford

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/55549/

[guybedford]

Node.js branching is a common problem here, I would recommend handling it fully if possible? See for example https://github.com/bytecodealliance/jco/blob/main/crates/js-component-bindgen/src/intrinsics.rs#L123.

[nicolo-ribaudo]

@guybedford I was thinking that maybe for Node.js we would want it to be synchronous, so that it can be compiled to CommonJS. Something like a @babel/plugin-proposal-import-source-to-node that transforms

import source x from "./x";

to

import { readFileSync } from "fs";
const x = WebAssembly.compile(readFileSync(import.meta.resolve("./x")));

[nicolo-ribaudo]

Actually, maybe it would be better to keep this plugin outside of the Babel org since it's Wasm/fetch-specific and not just based on ECMAScript 🤔

[liuxingbaoyu]

Actually, maybe it would be better to keep this plugin outside of the Babel org since it's Wasm/fetch-specific and not just based on ECMAScript 🤔

Technically I agree with this, but actually I think it would be nice to have it in the main repo too. (Shared test/release process, and more convenient modification and compatibility)

[nicolo-ribaudo]

I have been thinking about this more, and there are 4 possible transforms for import source x from "./x.wasm" depending on the target:

• ESM + browsers

  const url = import.meta.resolve("./x.wasm", import.meta.url);
  const x = await WebAssembly.compileStreaming(fetch(url));

• ESM + Node.js (this could also be asynchronous, but it's less spec compliant)

  import { createRequire } from "module";
  import fs from "fs";
  const path = createRequire(import.meta.url).resolve("./x.wasm");
  const x = WebAssembly.compile(fs.readFileSync(path));

• CJS + Node.js

  const fs = require("fs");
  const path = require.resolve("./x.wasm");
  const x = WebAssembly.compile(fs.readFileSync(path));

• Webpack

  import raw from "!!raw-loader!./x.wasm";
  const x = WebAssembly.compile(raw);

[guybedford]

For the ESM case, it can be useful to have a hybrid Node.js / browser output like I provided when eg creating a library on npm that supports both Node.js and browsers.

[nicolo-ribaudo]

@guybedford I added support for Node.js (we now have Web, Node, or Web+Node output). Could you review the generated code? 🙏

[nicolo-ribaudo]

The nodes generated by this function are not in @babel/helpers because they are highly dynamic (there are 13 possible cases), and they use import.meta which is module-dependent.

[nicolo-ribaudo]

Given that it's very likely that files would include just one .wasm import (I have never seen even whole packages with two .wasm entry points :) ), in the general case this would just make the code slightly bigger.

[nicolo-ribaudo]

Btw, I would expect the community to come up with their own bundler-specific plugins, such as the webpack output I showed above. It makes it possible to have much more bundler-integrated support!

[guybedford]

Seems good to me! Nice to get proper integration with the env targets. Are the version checks for import.meta.resolve reliable?

[nicolo-ribaudo]

@guybedford Are the version checks for import.meta.resolve reliable?

Hopefully :) It's data from MDN. If it's wrong, its a bug similar to how if compat data for any other plugin was wrong.

@liuxingbaoyu Technically I agree with this, but actually I think it would be nice to have it in the main repo too. (Shared test/release process, and more convenient modification and compatibility)

Now that the plugin is more complete, I'm ok with including it in this repository :)
Also, this is the only syntactic Stage 3 proposal that we do not currently support.

[liuxingbaoyu]

Would import fs from "fs"; be better?

[nicolo-ribaudo]

Maybe? Given that this is the node-specific output both would be ok.

[Jabriilmohame]

1000

[nicolo-ribaudo]

@liuxingbaoyu I still replaced process.versions.node with process.versions?.node, in case somebody has a bundler that replaces process with an object without the versions property, or that replaces process.versions with undefined.