Lann Martin (Feb 24 2026 at 14:25): Lann Martin (Feb 24 2026 at 14:25):@Karthik Ganeshram is looking at merging wasm-pkg-tools into wasm-tools. This was originally suggested by @Alex Crichton here: https://github.com/bytecodealliance/wasm-pkg-tools/issues/99
As an incremental step, would it make sense to move the code while retaining the separate wkg binary? All the messy networking code and deps could be maintained under those packaging repos while still getting some monorepo benefits. If (as suggested later in that issue) we wanted to move towards a plugin model then we would presumably want separate binaries anyway.
Alex Crichton (Feb 24 2026 at 15:24):Are you thinking that the non-networking guts would be moved first, and then the networking guts/binary moved?
Lann Martin (Feb 24 2026 at 15:27):I wasn't but that sounds fine. :shrug:
Alex Crichton (Feb 24 2026 at 15:28):Personally I'd say that the networking guts are predicted to be the biggest hurdle so I'd say it's probably not worth it to split out
Lann Martin (Feb 24 2026 at 15:28):I'd have to go look to see if that would make sense with the current crate splits
Alex Crichton (Feb 24 2026 at 15:29):I'd prefer to avoid a prolonged halfway-state where half the code is in one repo and half in the other
Alex Crichton (Feb 24 2026 at 15:29):and it'll probably be difficult to test with only half the code moved
Alex Crichton (Feb 24 2026 at 15:29):(in wasm-tools that is)
Lann Martin (Feb 24 2026 at 15:29):I was thinking that we'd just shift all the code in and do some minimal dep updates initially but I haven't really thought it through comprehensively.
Lann Martin (Feb 24 2026 at 15:30):I guess the key here is that we probably wouldn't add any new workspace deps
Alex Crichton (Feb 24 2026 at 15:30):eh that's ok, vetting isn't set up for wasm-tools yet -- I'd probably say that migrating the code and hooking up wasm-tools wkg, probably off-by-default, might be the first step
Alex Crichton (Feb 24 2026 at 15:31):next would be setting up the CLI to be as-desired, then turning it on-by-default
Alex Crichton (Feb 24 2026 at 15:33):I guess what I'm saying is don't worry about new deps and such for now, I think merging repos code-wise is good to do as one step while deferring integrations like the final CLI interface and the final release binaries to future PRs.
Alex Crichton (Feb 24 2026 at 15:34):that way the first step takes care of moving code, CI testing, initial crate organization, etc
Lann Martin (Feb 24 2026 at 17:26):(sorry - multiple meetings)
Lann Martin (Feb 24 2026 at 17:27):So you would prefer to go with a feature-flagged subcommand than a separate wkg binary?
Alex Crichton (Feb 24 2026 at 17:27):Personally yeah that's the way I'd go -- all subcommands are already feature-flagged for wasm-tools so this would fit in nicely there
Alex Crichton (Feb 24 2026 at 17:28):and my thinking of having it off-by-default for releases/workspace/etc initially is that it buys some more runway to bikeshed the CLI interface and such
Lann Martin (Feb 24 2026 at 17:31):This could maybe be discussed in a PR but I'm thinking the subcommand should maybe be a little more generic/boring. As much as I like dumb names, wkg doesn't really have any meaning apart from being a unique and memorable binary name and it would probably be more obvious as e.g. wasm-tools pkg
Alex Crichton (Feb 24 2026 at 17:32):heh you can see my inventiveness in names like wasm-tools as well
Alex Crichton (Feb 24 2026 at 17:32):but yeah happy to bikeshed on the final name, it's only sort of finalized once it's on-by-default so there's room to debate
Lann Martin (Feb 24 2026 at 17:33):Even then there are always aliases!
Lann Martin (Feb 24 2026 at 17:33):I'll update the issue based on this
Last updated: Mar 23 2026 at 16:19 UTC