pinning old version of wasm_bindgen makes dependency management difficult

[eric-seppanen]

Is there an existing issue for this?

• I have searched the existing issues

What version of workers-rs are you using?

0.0.18

What version of wrangler are you using?

n/a

Describe the bug

The worker crate pins the exact version of wasm_bindgen:

wasm-bindgen = "=0.2.87"

This makes it painful to add additional dependencies, because it forces the user to manually hunt around for older versions of crates that permit that exact version of wasm-bindgen.

As as example, here's what it's like to create a new project and then start adding other dependencies:

testing$ cargo add worker
    Updating crates.io index
      Adding worker v0.0.18 to dependencies.
             Features:
             - d1
             - queue
    Updating crates.io index
    
testing$ cargo add js-sys
    Updating crates.io index
      Adding js-sys v0.3.66 to dependencies.
    Updating crates.io index
error: failed to select a version for `wasm-bindgen`.
    ... required by package `worker v0.0.18`
    ... which satisfies dependency `worker = "^0.0.18"` of package `testing v0.1.0`
versions that meet the requirements `=0.2.86` are: 0.2.86

all possible versions conflict with previously selected packages.

  previously selected package `wasm-bindgen v0.2.89`
    ... which satisfies dependency `wasm-bindgen = "^0.2.89"` of package `js-sys v0.3.66`
    ... which satisfies dependency `js-sys = "^0.3.66"` of package `testing v0.1.0`

failed to select a version for `wasm-bindgen` which could resolve this conflict

The error isn't terribly clear, but the only solution is to find a version of js-sys that will accept the same version of wasm-bindgen that worker requires. Let's try the previous version:

testing$ cargo add [email protected]
    Updating crates.io index
      Adding js-sys v0.3.65 to dependencies.
    Updating crates.io index
error: failed to select a version for `wasm-bindgen`.
    ... required by package `js-sys v0.3.65`
    ... which satisfies dependency `js-sys = "^0.3.65"` of package `testing v0.1.0`
versions that meet the requirements `^0.2.88` are: 0.2.89

all possible versions conflict with previously selected packages.

  previously selected package `wasm-bindgen v0.2.86`
    ... which satisfies dependency `wasm-bindgen = "=0.2.86"` of package `worker v0.0.18`
    ... which satisfies dependency `worker = "^0.0.18"` of package `testing v0.1.0`

failed to select a version for `wasm-bindgen` which could resolve this conflict

Nope, maybe the one before that?

testing$ cargo add [email protected]
    Updating crates.io index
      Adding js-sys v0.3.64 to dependencies.
    Updating crates.io index
error: failed to select a version for `wasm-bindgen`.
    ... required by package `js-sys v0.3.64`
    ... which satisfies dependency `js-sys = "^0.3.64"` of package `testing v0.1.0`
versions that meet the requirements `^0.2.87` are: 0.2.89, 0.2.87

all possible versions conflict with previously selected packages.

  previously selected package `wasm-bindgen v0.2.86`
    ... which satisfies dependency `wasm-bindgen = "=0.2.86"` of package `worker v0.0.18`
    ... which satisfies dependency `worker = "^0.0.18"` of package `testing v0.1.0`

failed to select a version for `wasm-bindgen` which could resolve this conflict

And then the one before that...

testing$ cargo add [email protected]
    Updating crates.io index
      Adding js-sys v0.3.63 to dependencies.

I've noticed this problem with js-sys, wasm-bindgen-futures, and web-sys.

This isn't a great user experience and not one I am used to seeing with public crates. This version pinning goes against the usual expectation that we trust semver-compatibility between minor/patch releases; if there's no reason to pin the version, could this be relaxed to allow newer versions?

If pinning is necessary, could worker please stay up to date on wasm-bindgen releases? There have been multiple releases in the months since 0.2.86 was released.

Steps To Reproduce

1. Create a new crate.
2. cargo add worker
3. cargo add js-sys

[spigaz]

Have you tried using patches?

I add this on my Cargo.toml to override all my workers-rs dependencies:
[patch.crates-io]
worker = { git = "https://github.com/spigaz/workers-rs.git" }

I believe you might be able to do that by pointing to the wasm-bindgen, but probably the most advisable solution for you is to create your own fork of workers-rs, update it and use it, like I did, and I guess too many others...

Because in practice workers-rs appears to be unsupported for some time now.

[DylanRJohnston]

I've forked the repo for the same reason main...DylanRJohnston:workers-rs:main. Now I just need to figure out if it's worth writing the bindings for WebSocket Hibernation or just abandon using Rust in favour of Typescript :(

[spigaz]

A while back they announced on twitter that support for other languages was coming:

https://twitter.com/eastdakota/status/1720454051660194195

I'm guessing they plan to release some kind of workers-wasm.

I'm not sure when I'm going to get to the WebSocket Hibernation API...
Although I'll have to use them at some point. But I have a lot to do meanwhile, including adding the AI Bindings.

I already added some R2 missing checksum stuff, so in my case I believe TypeScript was always a mistake.

Adding support for testing with workerd is also planned because I need it, but I'll have to way for miniflare 3 to work on that, for now I just use plain unit tests with wasm-bingen-test, I don't use vitest for integration, although I use it a lot in TypeScript workers.

But a community led fork makes a lot of sense in my opinion.

[DylanRJohnston]

@spigaz I took a stab at writing the bindings for the Hibernatable Web Sockets and they work #434. Wasn't as hard as I thought once I read through the wasm_bindgen documentation.

[spigaz]

That's awesome! I had already seen it.

I might try to merge to my fork them when I get there. Thanks!

My experience has been that too, it always seems harder than it actually is in practice.

[Boscop]

I just ran into this same issue..

@DylanRJohnston Btw, now there's wasm-bidngen 0.2.90.

Why is it even pinned to a specific patch version? Doesn't it adhere to semver?

@spigaz

Because in practice workers-rs appears to be unsupported for some time now.

Any idea why? What's the alternative for Rust in workers? :)

[DylanRJohnston]

@Boscop I believe that wasm-bindgen is extremely unstable, every part of the toolchain must be using the exact same version. So you need to make sure that tools like wasm-pack and worker-build are all using the exact same version. This is probably why they pin an exact version.

I'm using nix to build the project so I'm working with wasm-bindgen directly and so not as concerned about it causing issues with 3rd party builders like worker-build

[spigaz]

@Boscop There alternative for now is for you to fork it and use the forked version which is very easy to use in rust.

I believe its because they diverted all the resources to their higher priority projects.

If I had to guess, I would say they might be working on a workers-wasm, that given that a lot of stuff is done supported directly by workerd, might bypass JS entirely making it faster, besides supporting other languages like ghey announced.

[eric-seppanen]

@DylanRJohnston:

I believe that wasm-bindgen is extremely unstable, every part of the toolchain must be using the exact same version.

I had a look the most-downloaded public crates that have a dependency on wasm-bindgen, to see if pinning the exact version is common, and it's not. In the top 20 or so crates, I couldn't find a single example of version pinning. What is it about this crate that makes it need a different strategy? Especially since that choice causes significant pain in downstream projects (i.e. incompatibility with newer versions of js-sys, wasm-bindgen-futures, web-sys, etc.)

I'm not sure what "every part of the toolchain" refers to, but anything built by Cargo will already unify on the same version.

[NicoZweifel]

I created a draft PR based on @spigaz' fork: #472

@eric-seppanen I am not sure if pinning the exact version is required, but if it is possible changing the dependency requirement to sth like >=0.2.90, < 3 seems much better imo.

[eric-seppanen]

My complaint (pinning to wasm-bindgen = "=0.2.87") was already fixed in e06193a.

[NicoZweifel]

My complaint (pinning to wasm-bindgen = "=0.2.87") was already fixed in e06193a.

I ran into the same issue with a >=0.2.9 dependency and wasn't sure if I should open a new issue.
I was able to use a fork+patch to continue working but it would be nice if the version wasn't pinned to an exact one.

[spigaz]

I created a draft PR based on @spigaz' fork: #472

My fork currently is based on workers-rs latest version, as workers-rs got updated and my R2 changes were merged into main.