Add `wasm-pkg-lock` crate

[lann]

This could probably just be adapted from https://github.com/bytecodealliance/cargo-component/blob/main/crates/core/src/lock.rs

Open question: Should there be a single e.g. wasm-pkg.lock file (per workspace) or should each tool pick its own name (like wit.lock today)? Would you ever want different resolved package versions for different tools in the same workspace?

[calvinrp]

I can't imagine that use case, at the moment. Maybe start simple and lazy evaluate if we need to change.

[lann]

Discussed this a bit with @fibonacci1729. There are tradeoffs with both lock-per-tool and one-lock-to-rule-them-all:

• With a lock file per tool, it is more likely for versions to get unexpectedly out of sync between - say - two language toolchains that need to share bindings
• With a single lock file it is tricky to reason about updates to the lock file; if one tool wants to upgrade a dependency, does that mean that another tool's dependency tree is also magically updated?

I think this is best resolved with prototyping, so I'm proposing the following initial approach:

• One file per workspace: wasm-pkg.lock
• Two different types of information in the lock file:
  • [[dependency]]s record a specific dependency specification, e.g. wasi:http@{>=0.2.0}
  • These will include a tools field listing the tool(s) that need this direct dependency: tools = ["wit", "cargo-component", "jco"] Each tool will be responsible for managing its own entry in this list. If a tool removing itself from this list makes the list empty, the entry is deleted.
  • [[package]]s, reflecting specific resolutions of both the direct dependencys and transitive dependencies
  • The initial behavior will be for there to be exactly one package matching each dependency. This implies that any "upgrade" operation may upgrade dependencies for all tools.
    • If we end up hating this, a different scheme could be adopted where each dependency would be explicitly linked to a package, allowing multiple different resolutions for overlapping dependency specs.

[thomastaylor312]

We just merged support for a basic lock file adapted from the wit tool in cargo component with the merge of #91. We can keep this open as we might need to do some more prototyping, but just wanted people to be aware