Unable to use any CDN for ESM
WebReflection opened this issue · 5 comments
With recent split of the wasm file from the main module and recent module changes where UMD is preferred (a pretty defunct module kind on the Web as inherently incompatible with ESM) it's fairly impossible to use a CDN to run this project.
Assuming I use this end point:
https://cdn.jsdelivr.net/npm/@ruby/wasm-wasi@2.5.0/dist/esm/browser.js
the import from @bjorn3/browser_wasi_shim breaks everything.
Assuming I use the CDN to deliver https://cdn.jsdelivr.net/npm/@ruby/wasm-wasi@2.5.0/+esm I don't get the same export fields or the same logic actually present in the previous export.
unpkg breaks with ?module appended, esm.run fails, jsdelivr can't serve ESM.
Is there any plan to ship a proper ESM module or a different folder / dist structure that could benefit from these CDNs?
REaching the counter .wasm file is OK-ish, even if elsewhere, but the entry ESM point is basically unusable, thanks.
I think https://cdn.jsdelivr.net/npm/@ruby/wasm-wasi@next/dist/browser/+esm would work for you. I am totally not sure why https://cdn.jsdelivr.net/npm/@ruby/wasm-wasi@next/dist/esm/browser.js/+esm does not work....
The issue is that from that CDN I can't infer the WASM but we removed Ruby support in polyscript due too many issues in following progress around multiple CDNs where we had no luck in making any combination work.
Once there will be a single ESM target file beside its WASM counterpart we'll surely reconsider adding support for Ruby. Wasmoon, Pyodide and MicroPython, among PHP and even QuickJS don't have such issue with targeting the standard browser environment such as ESM and provide the WASM counterpart from the very same CDN end point.
I think you can use the following URL combination of ESM and Wasm:
- https://cdn.jsdelivr.net/npm/@ruby/3.2-wasm-wasi@next/dist/browser/+esm
- https://cdn.jsdelivr.net/npm/@ruby/3.2-wasm-wasi@next/dist/ruby.wasm
That's why I removed deprecation warnings for them 68e68ac
I will try again but last time I had no luck ... exported things where different ... I'll try to see if that combination works though, it's still awkward to infer, but if those end points won't change later on, we might be good.
@kateinoigakukun I can confirm that combination provides the expected exports and I will keep using that very same end point to also grab the related ruby.wasm counterpart, thank you.