New @ruby/wasm-wasi package without .wasm?
WebReflection opened this issue · 8 comments
I just spotted the deprecation warning:
DEPRECATED(ruby-3_2-wasm-wasi): "browser.esm.js" will be moved to "@ruby/wasm-wasi" in the next major release.Please replace your `import * from 'ruby-3_2-wasm-wasi/dist/browser.esm.js';` with `import * from '@ruby/wasm-wasi/dist/browser.esm.js';`
However, it's not clear to me 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.
Your documentation is also a bit off around this deprecation.
Is there by any chance a will to move per version the ruby.wasm file within the main package? We pin the version and resolve the URL with ease this way, keeping track of versioning and 2 different URLs looks a bit unnecessary to me, or surely not ideal or user friendly, thank you!
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.wasmfiles for all Ruby versions in the@ruby/wasm-wasiis 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.
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/wasm-wasi@x.x.x/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...)
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!
Let me summarize the problem here:
First, there are several library consumer use cases.
- Static bundler using ES Module
require()in Node.js using CJS- Dynamic import using ES Module
<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:
- Next minor release:
- Remove deprecation messages from
dist/browser.esm.jsanddist/browser.umd.jsin per-version packages. - Create a new ES Module shim used only for use case 1 and show deprecation message.
- Next major release:
- Remove shims of all
.cjs.jsand.d.tsanddist/node.*.js.
@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/wasm-wasi@x.x.x/dist/ruby.js'is the ESM module- `import * from 'https://cdn.jsdelivr.net/npm/@ruby/wasm-wasi@x.x.x/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!
@WebReflection Hi. You can find .js and .wasm under the same base URL since 2.2.0 without any deprecation warning.
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.
@kateinoigakukun awesome, thanks for that!