Stream: wasi

Topic: Using the preview2 shim JS code


view this post on Zulip Karel Hrkal (kajacx) (Jul 17 2023 at 15:38):

Hello, I wanted to ask if I can use the JS preview 2 shim javascript code in my project, wasm-bridge.

The idea is to have an instantiate function in Rust that would load those files into js with js_sys::eval, something similar to what is done here, but it would be fully automated.

I would need to add these js files to the source of wasm-bridge and distribute them as part of the wasm-bridge crate. I can add a notice to the source code specifying where those files come from, or add the Apache 2.0 license to those files, kind of like I have done with wasm-bridge-macros.

You can also read this response for a more complete picture of the story.

Provides a single unified API to run WASM modules on the desktop using wasmtime, or on the web using js-sys. - GitHub - kajacx/wasm-bridge: Provides a single unified API to run WASM modules on the ...
I did like to use jco for handling wasi preview2 in browser_wasi_shim. Is it possible to use jco directly in the browser to take a wasm component, run the transpilation step and directly run it as ...

view this post on Zulip Guy Bedford (Jul 17 2023 at 17:24):

@Karel Hrkal (kajacx) you are welcome to use the code if you include the license. I would encourage contributing back any changes you make as opposed to forking where possible, as we are very much in need to contributors to the code as well.

view this post on Zulip Karel Hrkal (kajacx) (Jul 18 2023 at 10:17):

Thanks. I am not sure if the changes I want to make can be merged into the original source. For example, I will need to "massage" the JS code so that it can be loaded with js_sys::eval as opposed to with import. I assume that's not really what you want in the main project.

Anyway, my project is open source too, so anyone can look at the changes.

view this post on Zulip Guy Bedford (Jul 18 2023 at 17:24):

You should be able to pipe the code into a JS build tool to massage it into any output you need. For example esbuild can flatten the imports and just output a global script. While not only better from a code structure perspective, it would also create a path for upstreaming and downstreaming changes which I would highly encourage. WASI will be continuing to evolve and it would set up the process for keeping it updated without a huge amount of manual merging effort to get on that.

view this post on Zulip Karel Hrkal (kajacx) (Jul 19 2023 at 08:32):

Thanks. I intended to have two folders: "original" and "modified", both checked into version control, with a script that re-fetches the original from a git url and another script that "massages" the original. So any changes upstream could be propagated to my project with "a push of a button" and I would see what actually changed in the git diff.

ES build looks interesting, I will try using that. Also, if there will be any changes "fit" to be merged back upstream, I will create a pull request.


Last updated: Dec 23 2024 at 13:07 UTC