Exempt wasm-bindgen-related crates from version requirements

[LaurenzV]

We have a policy to 1) update all dependencies before a new release and 2) also specify the newest patch release that we use explicitly in the Cargo.toml. I think this makes sense in general, but I would like to propose that we except wasm-bindgen and the related crates from the second rule.

The reason for this is that wasm-bindgen is special, in the sense that there is an additional CLI tool you need to use and the version of the CLI tool must exactly match the one used by the crate. Therefore, by bumping wasm-bindgen with each version (which will become even more common assuming we start doing more regular releases), we create a lot of very unnecessary churn for consumers to update their wasm-bindgen CLI version, even though we don't really need any of the new features from a patch release. For example, I try to sync up my own repo vello_bench2 every once in a while with the newest git version. I also have a tendency to check out and run older revisions so I can test whether there has been any regression in a specific time frame. Because of this, I created an alias which allows me to easily switch between multiple versions, and while that works fine, I think it would be much better if we didn't force this kind of churn from the vello side in the first place. Curious to hear your thoughts. 🙏

Therefore, in this PR I have

1. Put those crates in the root Cargo.toml so they are synced across the repo.
2. Relaxed the version requirement to what we had before the bump. Happy to go down even further or do it another way that allows us to achieve the same goal.

[xStrom]

If the CLI needs to be the exact same wasm-bindgen version, then using the version pinning makes sense. Especially as it is for examples.

What about js-sys and web-sys though? Is there any interaction with wasm-bindgen? The versions aren't pinned, which is good because vello_hybrid depends on them, but also that seems to suggest that they don't need to be in-sync with wasm-bindgen. So, is there a reason they need to be part of the exemption?

Similarly, do the other two wasm-bindgen-* dependencies need to be in-sync? They're not currently pinned, which suggests no.

[LaurenzV]

What about js-sys and web-sys though? Is there any interaction with wasm-bindgen?

Yes, unfortunately they depend on wasm-bindgen:

│   └── web-sys v0.3.91
│       ├── js-sys v0.3.91
│       │   ├── once_cell v1.21.4
│       │   └── wasm-bindgen v0.2.114 (*)
│       └── wasm-bindgen v0.2.114 (*)

And they are also pinned to exact versions, so they need to be in sync: https://github.com/wasm-bindgen/wasm-bindgen/blob/0621e40fc716b89a6f558dc844fc9419d06b7d85/crates/web-sys/Cargo.toml#L26-L27

Same for wasm-bindgen-futures and wasm-bindgen-test, so it likely applies to all crates in that family.

[xStrom]

What a mess.

I am sympathetic to the goal of being able to use the same CLI version across revisions. The problem is that this will create the exact blindspot that the general policy is designed to avoid. Which is that vello_hybrid has js-sys and web-sys dependencies. Users will (automatically cargo) resolve these to various newer versions which we've never tested.

Maybe that is an ok risk for js-sys and web-sys in this case? I'm slightly leaning towards yes, it's worth the risk. I'm not fully sure.

[LaurenzV]

We can still make sure that the latest version is used in our lock files right? I can revert the change to the lock file. But we just shouldn’t be too strict in the Cargo.toml file itself, but as long as we’ve tested that vello works with the minimum version we provided it should be fine, right?