Remove public deps from wasm-metadata's API
#1130
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently whenever `wasmparser` or `wasm-encoder` have a major version bump this requires a major revision of `wasm-metadata` to be released due to their appearance in the API of `wasm-metadata`. This in turn forces a major version bump of `wit-component` due to `wit-component`'s usage of `wasm-metadata` in its public API. The `wasmparser` and `wasm-encoder` crates, however, are relatively "unstable" crates in that the amount of features they support for wasm are shifting quite a lot over time meaning that they have a lot of major version bumps. Coupling this rate of change to `wit-component` which is expected to be embedded in many WIT-related bindings generators I'm predicting won't be the best development story. To decouple these crates this commit removes the `wasmparser` and `wasm-encoder` types from the API of `wasm-metadata` by making them internal implementation details. After this it's possible to have a major revision of `wasmparser` without updating the major revision of `wasm-metadata` or `wit-component` for example.
pchickey
approved these changes
Jul 17, 2023
dhil
pushed a commit
to dhil/wasm-tools
that referenced
this pull request
Jul 21, 2023
Currently whenever `wasmparser` or `wasm-encoder` have a major version bump this requires a major revision of `wasm-metadata` to be released due to their appearance in the API of `wasm-metadata`. This in turn forces a major version bump of `wit-component` due to `wit-component`'s usage of `wasm-metadata` in its public API. The `wasmparser` and `wasm-encoder` crates, however, are relatively "unstable" crates in that the amount of features they support for wasm are shifting quite a lot over time meaning that they have a lot of major version bumps. Coupling this rate of change to `wit-component` which is expected to be embedded in many WIT-related bindings generators I'm predicting won't be the best development story. To decouple these crates this commit removes the `wasmparser` and `wasm-encoder` types from the API of `wasm-metadata` by making them internal implementation details. After this it's possible to have a major revision of `wasmparser` without updating the major revision of `wasm-metadata` or `wit-component` for example.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently whenever
wasmparserorwasm-encoderhave a major version bump this requires a major revision ofwasm-metadatato be released due to their appearance in the API ofwasm-metadata. This in turn forces a major version bump ofwit-componentdue towit-component's usage ofwasm-metadatain its public API.The
wasmparserandwasm-encodercrates, however, are relatively "unstable" crates in that the amount of features they support for wasm are shifting quite a lot over time meaning that they have a lot of major version bumps. Coupling this rate of change towit-componentwhich is expected to be embedded in many WIT-related bindings generators I'm predicting won't be the best development story.To decouple these crates this commit removes the
wasmparserandwasm-encodertypes from the API ofwasm-metadataby making them internal implementation details. After this it's possible to have a major revision ofwasmparserwithout updating the major revision ofwasm-metadataorwit-componentfor example.