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?

[nicoburns]

This policy of upgrading in Cargo.toml has caused a lot more problems than it's solved for me. When upgrading Blitz in the Dioxus repo (which transitively depends on Linebender crates), I regularly end up in situations where this makes the crate graph unresolvable (or forces us into an upgrade that breaks something or requires a bunch of work to make it compile). AFAIK, nobody else in the Rust ecosystem does this, and I'd much rather we didn't either.

wasm-bindgen is definitely particularly problematic in this regard, and if we're going to keep the policy then I'd support an exemption.

Users will (automatically cargo) resolve these to various newer versions which we've never tested.

Can't this can happen even with our policy if a newer version of a crate is published after we publish?

[DJMcNab]

My position would be:

• We (should!) pin a specific, lower version of wasm-bindgen, so the issue that we only test with newer deps doesn't apply.
• Any user who needs this feature should already be pinning their own version of wasm-bindgen. As such, I'm happy to say that any breakage resulting from a wasm-bindgen upgrade is the user's responsibility, as they will be explicitly upgrading the external dependency. This is similar to our position with rustc; we only guarantee we work on the rustc we've tested with, and that by upgrading rustc, you're taking on the risk that Rust broke us (but we'll fix any issues caused by new stables when we upgrade Rustc).

To spell it out, I do believe that wasm-bindgen specifically can be an exception to our policy, and so agree with this PR.

That being said, this can't land as-is for the reason explained in my PR comment.

I don't like that js-sys/web-sys have to be included here, but they do unfortunately pin a specific wasm-bindgen version, and likely have synced releases with wasm-bindgen.

[DJMcNab]

I'm not certain that this one is right; we still need to pin an exact version, so as to avoid a benign Cargo.lock bump breaking CI.

(That is, we specifically build this crate for WASM, so it needs to pin the version it uses. The same applies for all the example crates, I believe)

[DJMcNab]

As a piece of evidence here, consider the insane situation that this PR hasn't needed to change the version in the CI file. That's definitely wrong.

[LaurenzV]

We (should!) pin a specific, lower version of wasm-bindgen, so the issue that we only test with newer deps doesn't apply.

Am I understanding correctly that you are talking about with_winit specifically, and not for the whole workspace? if so, that makes sense to me, but for Vello Hybrid, the whole point is that clients can choose a version, so there we don't want to pin to a specific version, right?

[DJMcNab]

Yes, we need to pin for examples, but not for the library crates.

[LaurenzV]

Okay so:

• Both, web-demo.yml and with_winit are now pinned to 0.2.114 for wasm-bindgen. In with_winit, I've still chosen to use the workspace version for wasm-bindgen-futures and web-sys, which should be fine because the pin of wasm-bindgen will force the correct version of those anyway, as long as the minimum versions defined in Cargo.toml are not higher than 0.2.114, which they are not. Let me know if you still would prefer explicit versions.
• I have not pinned the versions for the vello_cpu/vello_hybrid examples, since there doesn't seem to be any requirement for that from the CI side as far as I can tell, even though they aren't library crates.

I hope that resolves the concerns that you had!