feat(client,cli): add multi-packaging support for wkg publish

[mkatychev]

Added the ability to publish multiple WIT packages at once.
Introduced the PublishPlan struct to resolve local references into a sequence of batches for publication:

wasm-pkg-tools/crates/wasm-pkg-core/src/resolver.rs

Lines 846 to 853 in 40d2dd3

	/// State for tracking dependencies during upload.
	pub struct PublishPlan {
	/// Graph of publishable packages where the edges are `(dependency -DependencyOf->) dependent)`
	dependents: DependencyGraph<PackageSpec>,
	// TODO look at using cargo's `InternedString` type for `PackageRef`:
	// https://docs.rs/cargo/latest/cargo/util/interning/struct.InternedString.html
	indices: LocalPackageIndex,
	}

Reference implementation (cargo multi-package publishing):

• https://www.tweag.io/blog/2025-07-10-cargo-package-workspace/
• https://github.com/rust-lang/cargo/pull/14433/changes

[vados-cosmonic]

Hey I took a pass through, a lot of NITs but it looks mostly good to me!

One thing I'd love to have is a few more tests... This is a pretty substantial feature, so figured there would be more edges/fixtures. That said, we can certainly add tests down the line if we run into anything.

[vados-cosmonic]

Are we sure this will always terminate? Should we add a check just in case? We're not allowed to have cycles AFAIK so maybe I'm being a bit too defensive here.

[mkatychev]

You're totally right, cargo's take_ready bakes in a timeout.
EDIT: forgot to post link:
https://github.com/rust-lang/cargo/blob/a595d0da21f228b7fdae64d3d5c0e527ea66bb59/src/cargo/ops/registry/publish.rs#L289-L294

[vados-cosmonic]

Oh Ok great! but it's not like... async? I think I actually have more questions now -- I was wondering if it's possible for ready_for_publish to not have anything in it and the plan to not be empty, essentially.

Not looking for a proof or anything of course, but basically... could the graph be misconfigured in a way that nodes are kinda hanging out but don't end up looking ready? The answer could easily be "absolutely not" and then this isn't an issue, but a small invariant check (i.e. "if plan is empty, take_ready will always produce at least one thing to do on each iteration") would be nice

[mkatychev]

Here's what I've reasoned myself into:

• ready_for_publish is guaranteed to be nonempty IF !plan.is_empty() and
  • a DependencyGraph (petgraph::Acyclic) will produce AcyclicEdgeError errors during try_update_edge for any "danging graphs"¹
• a node is determined to be ready when it has zero Incoming edges²:
  

  wasm-pkg-tools/crates/wasm-pkg-core/src/resolver.rs

  Lines 899 to 902 in c26b6bf

  	self.dependents
  	.neighbors_directed(*id, Direction::Incoming)
  	.count()
  	== 0

The one area we don't have guarantees is if PackagePublisher::publish will ever terminate.

Footnotes

1. https://github.com/bytecodealliance/wasm-pkg-tools/blob/8555d1bbee9ac20290b5516437f35346add95be0/crates/wasm-pkg-core/src/wit.rs#L216-L227 ↩

2. https://docs.rs/petgraph/latest/src/petgraph/graph_impl/mod.rs.html#913 ↩

[vados-cosmonic]

IMO @mkatychev this would make for a great comment close in the code!

[mkatychev]

@vados-cosmonic for PublishPlan, the need for pub is because it is instantiated inside of wkg proper, this is also true for all the methods within and inner types (except for PublishPlan::len but that one makes sense to be exposed):

wasm-pkg-tools/crates/wkg/src/main.rs

Line 279 in 778b1cc

let mut plan = PublishPlan::from_paths(paths)?;