Skip to content

Add wasm-module to wast dependency #2098

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

Merged
merged 1 commit into from
Mar 13, 2025

Conversation

alexcrichton
Copy link
Member

This fixes an unfortunate series of events which renders most historical builds of wasm-tools un-buildable from crates.io without --locked. The basic problem here is of this shape:

  • The wasm-tools CLI requires the wasm-module feature to be enabled in wast but doesn't explicitly enable it.
  • The wasm-tools crate depends on wat, which by default enables this feature. This is why everything "works" today.
  • Once published the wat crate has semver-compatible releases, meaning that a historical wasm-tools may pull in a newer wat.
  • If a historical wasm-tools pulls in a newer wat then it'll activate the wasm-module dependency in a different version of wast, meaning the CLI doesn't have the feature enabled in its dependency of wast.

I'm not sure how it would be possible to detect this on CI and fix this or otherwise have a check against it. Thankfully using --locked at least for historical builds works (but that shouldn't be required).

This fixes an unfortunate series of events which renders most historical
builds of `wasm-tools` un-buildable from crates.io without `--locked`.
The basic problem here is of this shape:

* The `wasm-tools` CLI requires the `wasm-module` feature to be enabled
  in `wast` but doesn't explicitly enable it.
* The `wasm-tools` crate depends on `wat`, which by default enables this
  feature. This is why everything "works" today.
* Once published the `wat` crate has semver-compatible releases, meaning
  that a historical `wasm-tools` may pull in a newer `wat`.
* If a historical `wasm-tools` pulls in a newer `wat` then it'll
  activate the `wasm-module` dependency in a different version of
  `wast`, meaning the CLI doesn't have the feature enabled in its
  dependency of `wast`.

I'm not sure how it would be possible to detect this on CI and fix this
or otherwise have a check against it. Thankfully using `--locked` at
least for historical builds works (but that shouldn't be required).
@alexcrichton alexcrichton added this pull request to the merge queue Mar 13, 2025
Merged via the queue into bytecodealliance:main with commit 5aa5315 Mar 13, 2025
32 checks passed
@alexcrichton alexcrichton deleted the add-featur branch March 13, 2025 16:45
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

Successfully merging this pull request may close these issues.

2 participants