New @ruby/wasm-wasi package without .wasm? about ruby.wasm

[kateinoigakukun]

@WebReflection Hi. You can find .js and .wasm under the same base URL since 2.2.0 without any deprecation warning.

• https://cdn.jsdelivr.net/npm/[email protected]/dist/browser.esm.js
• https://cdn.jsdelivr.net/npm/[email protected]/dist/ruby.wasm

[kateinoigakukun]

I had a closer look at your case. It looks like you are importing the browser.esm.js with dynamic import, so your case might be able to be mitigated by just putting export * from 'https://cdn.jsdelivr.net/npm/@ruby/[email protected]/dist/browser.esm.js'; as browser.esm.js in version-specific package. (I still need to figure out a way to make it work with static bundler tools...)

[kateinoigakukun]

Thanks for your detail report and sorry for my late response (I couldn't participate any OSS work for a while due to some contracts)

I'm very happy to hear that polyscript supports Ruby!

why I need one CDN to grab @ruby/wasm-wasi/dist/browser.esm.js and another CDN url to grab its ruby-3_2-wasm-wasi@latest/dist/ruby.wasm counterpart.

The main reason for splitting into different packages is to share browser.esm.js among multiple Ruby versions.

Version specific packages (e.g. ruby-3_2-wasm-wasi) will contain only .wasm file and short script just for <script> tag soon and core @ruby/wasm-wasi package contains Ruby version independent things.

Your documentation is also a bit off around this deprecation.

Thank you for pointing out. That's my bad. Will update it soon.

Is there by any chance a will to move per version the ruby.wasm file within the main package?
Unfortunately, embedding .wasm files for all Ruby versions in the @ruby/wasm-wasi is unrealistic due to package size limit of jsdelivr CDN.

I know it's not ideal for your use case and it would be non-trivial cost to maintain two versions of the packages. One of the mitigations would be reading dependencies field of package.json at runtime and extracting the dependent @ruby/wasm-wasi version.

I'm still exploring a way to satisfy the multi Ruby version requirement and user friendliness at the same time.

[WebReflection]

as polyscript supports Lua (wasmoon), Python (pyodide + micropython), PHP (experimental), QuickJS (experimental), WebR (experimental) and whatnot, we'd love to fully support Ruby (half-experimental, it works great already for some use case) and we inevitably load interpreters and related code lazily, otherwise the project would die behind 50MB download to start with 😅

I appreciate you looking into it, we can always pin-point default versions ourselves, the thing is that in polyscript one can explicitly define a Ruby version indeed, and we've no idea where to grab its WASM related counterpart to make it work ... the default can work fine, but users opting for another version would be hard for us to track.

If the dance out of a specific version can be bound to the very same URL, everything would be fine, as it's been until now, thank you!

[kateinoigakukun]

Let me summarize the problem here:

First, there are several library consumer use cases.

1. Static bundler using ES Module
2. require() in Node.js using CJS
3. Dynamic import using ES Module
4. <script> tag using IIFE and UMD

In 1 and 2, they can simply replace their import "ruby-3_2-wasm-wasi/dist/browser" or require("ruby-3_2-wasm-wasi/dist/browser") statement with new @ruby/wasm-wasi version since the corresponding @ruby/wasm-wasi version is already resolved and installed under node_modules directory.

But 3 and 4 cannot easily grab the corresponding @ruby/wasm-wasi since there is no npm install phase or something like that.

So I decided to keep placing ES Module and UMD shims only for 3 and 4 use cases. My deprecation plan is:

1. Next minor release:

• Remove deprecation messages from dist/browser.esm.js and dist/browser.umd.js in per-version packages.
• Create a new ES Module shim used only for use case 1 and show deprecation message.

2. Next major release:

• Remove shims of all .cjs.js and .d.ts and dist/node.*.js.

[WebReflection]

@kateinoigakukun I am not sure I am following but ESM is the only way forward for JS. On the web, our issue is that we don't know where to find the .wasm file because it's in a different module. We can hard-code that but it will play badly for users' custom versions for testing purpose or whatnot.

To us, like it is for every other project we deal with until now, we expect the following:

• import * from 'https://cdn.jsdelivr.net/npm/@ruby/[email protected]/dist/ruby.js' is the ESM module
• `import * from 'https://cdn.jsdelivr.net/npm/@ruby/[email protected]/dist/ruby.wasm' is the related WASM engine

UMD is a dead standard, it breaks with ECMAScript standard modules and it's been abandoned by everyone.

CJS is still used in Node but ultimately both bun and deno and every browser uses ESM so it's less interesting as a target and node deals very well with ESM too since version 16+.

Is there by any chance the will to provide such simple approach so that both versioning of the module and the WASM file are always in sync and we need to deal only with one pre-resolved CDN URL instead?

Thanks!

[kateinoigakukun]

I considered moving all .wasm binaries for all Ruby versions into @ruby/wasm-wasi but I didn't do it because it makes the package size over 200mb even though user wants to use a single version of Ruby. And also jsdelivr limits the package size to be under 150mb to be hosted on the CDN.

[WebReflection]

@kateinoigakukun awesome, thanks for that!