Wasmtime GitHub notifications bot (Oct 07 2025 at 22:18): Wasmtime GitHub notifications bot (Oct 07 2025 at 22:18):alexcrichton requested fitzgen for a review on PR #11805.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:18):alexcrichton opened PR #11805 from alexcrichton:wizer to bytecodealliance:main:
This PR is the first step in what will be a few to merge the wizer and component-init repositories into this main repository. The goal is to consolidate these features here in Wasmtime and provide it as part of the
wasmtimeCLI itself. This is intended to reduce maintenance burden by only having one repo to manage instead of multiple. To that end the changes in this PR are:
- The https://github.com/bytecodealliance/wizer repository is copied, without its git history, into the
crates/wizerfolder.- Subsequent commits adjust CI integration files, other management files, etc, to all fit within Wasmtime's repository.
- Commits then get the new
wasmtime-wizercrate compiling in this workspace and passing tests.- Commits then create a new
wasmtime wizersubcommand which has the same arguments/behavior ofwasmtime runby literally using the same implementation of execution internally (e.g. supports all WASI proposals and such)- Finally there's assorted miscellaneous things like getting the fuzzer compiling, benchmarks compiling, etc.
Overall I think this is in a good-enough state to upstream into this repository as a first step. The next step will be to refactor the internals of
wasmtime-wizerto be amenable for sharing withcomponent-inititself. This'll include trying to makewasmtime-wizermore runtime-agnostic by, in theory, having just a single trait that a runtime need implement and severing the dependency onwasmtime(or at least optionally severing the dependency).With such refactorings in place the next step I'd take is to fold the component-init repository into
wasmtime-wizer. That'll require yet more reorganization and finesse though so I'd like to split this across multiple PRs instead of having one large PR.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:18):alexcrichton requested wasmtime-core-reviewers for a review on PR #11805.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:18):alexcrichton requested wasmtime-default-reviewers for a review on PR #11805.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:30):alexcrichton updated PR #11805.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:46):alexcrichton updated PR #11805.
Wasmtime GitHub notifications bot (Oct 07 2025 at 23:12):cfallin commented on PR #11805:
The https://github.com/bytecodealliance/wizer repository is copied, without its git history, into the crates/wizer folder.
Just a comment from general principles but I like that we've tried to preserve git history in other repo merges that we've done (e.g., Cranelift into Wasmtime and ISLE prototyping into Cranelift are two off the top of my head). It's nice to continue to have the git-blame and feels right re: authorship records. Would you be opposed to pulling in the separate git lineage, appending a commit that moves the thing to the right subtree, and joining it all with a merge-commit?
(Now that I say this, I realize the above two other merges happened before we universally squashed on merge, so maybe this isn't viable unless we break that policy temporarily...)
Wasmtime GitHub notifications bot (Oct 08 2025 at 11:28):tschneidereit commented on PR #11805:
we've tried to preserve git history in other repo merges that we've done
An alternative to this would be to add an
AUTHORSfile explaining the code's heritage and pointing to the original wizer repo. I've used this approach when creating the StarlingMonkey repository to keep a paper trail back to Fastly's js-compute-runtime.
Wasmtime GitHub notifications bot (Oct 08 2025 at 14:49):alexcrichton commented on PR #11805:
I'm fine to go either way on the history myself. I didn't bother splicing it in due to the squash merging strategy we have which would have erased it anyway. I'd be fine though integrating the history with a special merge commit and then layer this PR on top of that.
Wasmtime GitHub notifications bot (Oct 08 2025 at 14:55):fitzgen commented on PR #11805:
+1 for preserving history. It is very useful for things like bisecting.
Also, we preserved it when we imported Cranelift into Wasmtime, the mach backend into Cranelift, and ISLE into Cranelift. I don't know why we'd do something different this time around.
Wasmtime GitHub notifications bot (Oct 08 2025 at 16:04):alexcrichton commented on PR #11805:
Ok I've got a history-preserving version over at https://github.com/bytecodealliance/wasmtime/pull/11815. I plan on discussing this in tomorrow's Wasmtime meeting to ensure everyone's on board with the particulars of how exactly the merge is done. Assume all goes well the plan would then be to merge #11815 which has all of Wizer's history, rebase this PR which would largely just drop the first commit, and then this PR would get all squashed into one and would be the "integrate wasmtime and wizer" PR
Wasmtime GitHub notifications bot (Oct 08 2025 at 16:07):alexcrichton updated PR #11805.
Wasmtime GitHub notifications bot (Oct 09 2025 at 20:13):alexcrichton updated PR #11805.
Last updated: Dec 06 2025 at 06:05 UTC