Skip to content

wasm-tools in wasm & JS #2374

Open
Open

Description

@vados-cosmonic

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).

The end goal is for a project like @bytecodealliance/componentize-js to import @bytecodealliance/wams-tools-metadata like so:

import { addMetadata } from '@bytecodealliance/wasm-tools-metadata/wasm/transpiled';

async addProducerMetadata(fields) {
    const wasmBytes = readFile(...);
    const updatedBytes = addMetadataSection(bytes, { producer: fields });
    return updatedBytes;
}

Activity

  1. alexcrichton commented on Nov 12, 2025

    @alexcrichton
    Member

    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.

  2. bakkot commented on Nov 18, 2025

    @bakkot
    Contributor

    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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions