You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing I've been thinking about was making a project that essentially provided all the wasm-tools that could be compiled to WASM in wasm, with WITs to expose their functionality.
We do this already informally in Jco via the wasm-tools-component subproject, but it would be great to get this functionality upstream and built into the release processes, etc.
Thanks to @tschneidereit to noting that I should make an issue to get the discussion started on this.
Happy to work on this of course and build this against this repo itself or build it on the side and use the rust crates as dependencies to prove it out and integrate via PR afterwards once we're happy with it.
P.S. In addition to having Wasm produced for individual tools (we could also do an amalgam with some composition of course), it would also be very convenient to have the transpiled (as in jco transpiled) versions be available somewhere (this likely fits better downstream) so that users have another way to consume the libraries (via a JS package and Wasm components directly).
I'm all for this myself, I think it's a great idea! Infrastructure-wise I'd say that the source for this should probably live in this repository in a similar fashion as the C API living in this repository as well. That being said I'm not well-versed on how to setup a JS project and publishing to npm and such, so assistance on that would be much appreciated.
Note that there's already wasm builds of print and parse created as part of the playground. I doubt it's much help for this effort, but in the other direction if this ends up happening we could presumably remove the cargo build part of creating the playground and just depend directly on the artifacts produced by this effort. (At the cost of potentially larger artifacts, though maybe that can be fixed by a pass of wasm-opt.)
Activity
alexcrichton commentedon Nov 12, 2025
I'm all for this myself, I think it's a great idea! Infrastructure-wise I'd say that the source for this should probably live in this repository in a similar fashion as the C API living in this repository as well. That being said I'm not well-versed on how to setup a JS project and publishing to npm and such, so assistance on that would be much appreciated.
bakkot commentedon Nov 18, 2025
Note that there's already wasm builds of
printandparsecreated as part of the playground. I doubt it's much help for this effort, but in the other direction if this ends up happening we could presumably remove thecargo buildpart of creating the playground and just depend directly on the artifacts produced by this effort. (At the cost of potentially larger artifacts, though maybe that can be fixed by a pass of wasm-opt.)