Merged
Conversation
This adds two new features: - Multiple `--world` options are accepted, in which case the worlds will be merged into a single world for building, testing, or bindings generation. - In addition to any worlds and/or WIT paths specified explicitly via CLI options, `componentize-go` will use `go list` to scan the current module and its dependencies, looking for files named `componentize-go.toml` in their source trees. For each such file found, any worlds and/or WIT paths referenced therein will be added to the respective lists. This behavior can be disabled using the `--ignore-toml-files` option if desired. In combination, these options make it easier to use multiple SDKs or other libraries which contain `wit-bindgen-go`-generated code. Note that I've also removed the `wat` dependency because `go build` always generates a binary Wasm file, so no need to check for or parse WAT. Fixes bytecodealliance#28
dicej
force-pushed
the
remove-mod-option
branch
from
aaba6fe to
303f6f3
Compare
…via CLI Previously, we'd union all the worlds specified via the CLI _and_ via `componentize-go.toml` files, but that can get very confusing for the user. Now we'll only use the toml file ones as a default if none are specified via the CLI.
This also adds a test for the case, updates the WASIp3 WIT files to 0.3.0-rc-2026-03-15, and updates the Wasmtime used in CI to 43.0.0.
This was only used for the build subcommand, but all subcommands potentially need to know where the go module is e.g. to locate `componentize-go.toml` files, so we should either promote it to be a subcommand-independent option or drop it and require that `componentize-go` be run in the directory containing the module of interest. I chose the latter in this case, but we could certainly revisit that.
asteurer
approved these changes
Apr 1, 2026
Contributor
asteurer
left a comment
asteurer
left a comment
There was a problem hiding this comment.
Yeah, I think it's the right approach to require the user to be in the same directory as the go.mod file
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This was only used for the build subcommand, but all subcommands potentially
need to know where the go module is e.g. to locate
componentize-go.tomlfiles,so we should either promote it to be a subcommand-independent option or drop it
and require that
componentize-gobe run in the directory containing the moduleof interest. I chose the latter in this case, but we could certainly revisit
that.
Note that this builds on #35 and shouldn't be merged until that one is merged.