wasm-bindgen: version mismatch error message doesn't propose a working fix

Describe the Bug

Via using the trunk tool on my project, I encountered this warning:

Jul 13 11:58:31.495  INFO calling wasm-bindgen
error: 

it looks like the Rust project used to create this wasm file was linked against
version of wasm-bindgen that uses a different bindgen format than this binary:

  rust wasm file schema version: 0.2.69
     this binary schema version: 0.2.74

Currently the bindgen format is unstable enough that these two schema versions
must exactly match. You can accomplish this by either updating the wasm-bindgen
dependency or this binary.

You should be able to update the wasm-bindgen dependency with:

    cargo update -p wasm-bindgen

or you can update the binary with

    cargo install -f wasm-bindgen-cli

if this warning fails to go away though and you're not sure what to do feel free
to open an issue at https://github.com/rustwasm/wasm-bindgen/issues!

Jul 13 11:58:31.516 ERROR ❌ error
error from HTML pipeline

Caused by:
    0: failed to spawn assets finalization
    1: wasm-bindgen call returned a bad status

Neither of the suggested fixes did anything, since a project dependency required exactly version 0.2.69.

What did work was cargo install -f wasm-bindgen-cli --version 0.2.69. Perhaps wasm-bindgen should suggest this as well.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 7
Comments: 24 (2 by maintainers)

Commits related to this issue

Improved version mismatch error message Fixes #2619 Signed-off-by: Oliver T <geronimooliver00@gmail.com> — committed to snOm3ad/wasm-bindgen by snOm3ad a year ago

Most upvoted comments

I’m happy to help if you could provide more details.

Hi I had to additionally delete all my cargo.lock files and do a clean. This resolved it for me.

jsoneaday on Jun 26, 2023

It seems to me that you are using Trunk, which also seems to directly interact with the Cargo.lock file, so the bug might be with Trunk in this case.

daxpedda on Jan 14, 2024

It’s kind of hard to get into this state. In my case, I had a standalone crate, which later I put into a workspace. A good amount of time had passed between my original creation of the crate until I put it into the workspace and ran into this issue. So I think that to reproduce it, not only you need to bring into a workspace a crate with Cargo.lock, but it seems like the the two Cargo.lock must have a version mismatch. In my case, because it had been quite a while, I think the Cargo.lock in the crate I brought into the workspace was behind.

So I’m not 100% certain how to recreate the issue, however, I would suggest to keep in mind that this can happen to others later in the future, and that’s how we can track the cause.

Because I already resolved it, I don’t have a workspace I can share, but if I end up having the same problem, I’ll come back with the relevant data and to try and provide more info. Just keep in mind that this will probably happen again to others until we can hone in on the cause.

Also, thanks a lot for keeping an eye on this and your support!

jreniel on Jan 2, 2024

I can attest to the fact the removing Cargo.lock from the members works, but I can also say that it’s safe to recreate them (then it works). I’m only speculating but I think this comes from version mismatch between 2 Cargo.lock files.

jreniel on Dec 30, 2023

I’m happy to help if you could provide more details.

Hi I had to additionally delete all my cargo.lock files and do a clean. This resolved it for me.

I struggled with this for a while, and removing Cargo.lock fixed it me for as well. What had me stumped is that trunk would error out, but would be serving an entirely different project!

jreniel on Nov 1, 2023