Export WASM_FILE_PATH from @ruby/3.2-wasm-wasi and @ruby/head-wasm-wasi

[terrablue]

In the cheat sheet, this line is used:

const binary = await fs.readFile("./node_modules/@ruby/3.2-wasm-wasi/dist/ruby.wasm");

That's a bit flaky and would break if you moved this file elsewhere.

Would it be possible to export a WASM_FILE_PATH from @ruby/3.2-wasm-wasi and @ruby/head-wasm-wasi such that it is a resolved absolute path to the Wasm binary?

The NodeJS cheat sheet would then look like this:

import fs from "fs/promises";
import { DefaultRubyVM } from "@ruby/wasm-wasi/dist/node";
import { WASM_FILE_PATH } from "@ruby/3.2-wasm-wasi"; // or from "@ruby/head-wasm-wasi"

const binary = await fs.readFile(WASM_FILE_PATH);
const module = await WebAssembly.compile(binary);
const { vm } = await DefaultRubyVM(module);
vm.eval(`puts "hello world"`);

Could this be considered?

[kateinoigakukun]

I think we will not be able to move the .wasm files since many existing users already refer to the path via Node.js and CDN endpoints. but it's worth considering having such abstraction for future users.

I'm not sure what is the common way to do this in JavaScript ecosystem, so collecting real world examples would be helpful for our decision.

[terrablue]

You can retain backward compatibility by keeping the files where they are and just having the abstraction point to the right path. Or break compatibility with your next major.

I'm not really aware of comparable examples in the JavaScript ecosystem, where one package provides the 'environment' and another a piece of data to be loaded into that environment. It might be an oddly specific Wasm-related constellation. But hard-coding paths isn't common, as far as I'm aware.

FWIW, I'm using the pyodide package for Python Wasm, and there there is just one export which takes care of everything. But I'm not sure that's applicable to this situation, where you can alternate between 3.2 and head.

[kateinoigakukun]

Closed by #372