Skip to content

Merge into upstream wasm-tools? #153

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
alexcrichton opened this issue Mar 18, 2025 · 3 comments
Open

Merge into upstream wasm-tools? #153

alexcrichton opened this issue Mar 18, 2025 · 3 comments

Comments

@alexcrichton
Copy link
Member

I wanted to open an issue on this to perhaps discuss this. Currently wasm-tools compose prints a warning (rightfully) to use wac and in the future the plan is to sunset wasm-tools compose and the wasm-compose crate entirely. That being said one of the key benefits of wasm-tools compose is that it's "always in sync" with the rest of wasm-tools, basically entirely because it's in the same repository. I like the idea of having the two in sync, so wanted to raise the question: would it makes sense to migrate this repository to living within wasm-tools?

The benefits of such a merge could be:

  • Integrated release cadence with wasm-tools
  • Up-to-date bindings to wasm-tools crates
  • Up-to-date on the latest component model features
  • (maybe) Better visibility for functionality

Downsides, however, are:

  • Monorepo vs multi-repo - CI is more complicated, sweeping changes to the monorepo are harder (e.g. not all contributors will be familiar with wac)
  • Less focused issue tracker (more monorepo vs multi-repo)
  • More frequent "breaking" releases for functionality that's probably not actually breaking

Would maintainers/folks here be interested in such a merge? Or best to keep things separate?

@alexcrichton
Copy link
Member Author

Another possibility: merging some of the core functionality such as document parsing, resolve, etc, into wasm-tools but otherwise leaving out anything that would require networking. That would mean that the wac CLI would still exist for the purpose of doing networking and having various defaults, but for purely local cases wasm-tools compose could be repurposed to have simlar functionality to wac (and be backed by wac)

@fibonacci1729
Copy link
Collaborator

fibonacci1729 commented Mar 21, 2025

Personally I'm on board with this 👍 I like the plan to keep the cli separate so as to not introduce registry networking shenanigans into wasm-tools and just take a dependency here on wasm-tools

@fibonacci1729
Copy link
Collaborator

fibonacci1729 commented Apr 7, 2025

I'm going to start digging into this this week.

First going to bring the various crates up-to-date with wasm-tools.

Just saw #154 to bring things mostly up-to-date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants