wasm-bindgen
wasm-bindgen copied to clipboard
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.
Perhaps it would be useful to print out which packages require specific versions that do not match up with installed version.
Usually this error occurs because the wasm file was created using a version of wasm-bindgen
that differs from the version that wasm-bindgen-cli
is using. So to fix it, you either recompile your wasm module using the wasm-bindgen
version of your wasm-bindgen-cli
binary or you install the wasm-bindgen-cli
version that matches that of your wasm module. Something like this would be better?
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 this binary or the wasm-bindgen dependency in the Rust project.
You should be able to update the wasm-bindgen dependency with:
cargo update -p wasm-bindgen --precise <wasm-bindgen-cli version>
don't forget to recompile your wasm file. Alternatively, you can update the binary with
cargo install -f wasm-bindgen-cli --version <wasm file version>
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!
That looks good, would you mind making a PR?
I'm having a similar issue but only when I add the project into a workspace and in my case updating the cli does nothing. The same project outside of the workspace builds fine with trunk serve.
I'm happy to help if you could provide more details.
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.
In my case, I needed to use the Cargo syntax to specify that only a specific version can be used. I would also recommend deleting Cargo.lock
and cleaning your target
folder.
wasm-bindgen = "=0.2.86"
wasm-bindgen-cli = "=0.2.86"
wasm-bindgen-futures = "=0.4.36"
I don't know why this is necessary and it was particularly difficult to solve.
It isn't, but it's necessary to get the installed binary and the dependency version to match.
If you used cargo update
then this will update wasm-bindgen
to v0.2.87, so you will have to either update the binary or downgrade the dependency, you have opted to downgrade the dependency.
If deleting Cargo.lock
or the target
folder is really necessary, then this would be a bug in Rust or Cargo and not in wasm-bindgen
.
The error message should be quite clear, I'm interested in how it could be further improved.
Recompiling the wasm file with cargo build --target wasm32-unknown-unknown
should fetch the updated version of wasm-bindgen
and automatically update the contents of the target folder. There should be no need to delete the Cargo.lock
nor the target
dir.
It depends on what version of wasm-bindgen
you're using, but the newest message states:
don't forget to recompile your wasm file!
If this doesn't work, then I agree with dax it's a bug with cargo.
Apologies, I should've specified that my problem wasn't the fault of wasm-bindgen
.
There is a high possibility that I did something incorrectly so maybe it wasn't a Cargo bug.
As previously mentioned, the solution was to use the specific version syntax that I found from this Stack Overflow answer.
If this is an issue with Cargo, it might be a good idea to include the aforementioned syntax in the error message e.g.
if the above methods fail, try the following syntax which forces Cargo to use the specified dependency version:
wasm-bindgen = "= 0.2.86"
wasm-bindgen-cli = "= 0.2.86"
If this is an issue with Cargo, it might be a good idea to include the aforementioned syntax in the error message [..]
This is actually not needed, the current error message tells you how to fix this probably in a better way:
cargo update -p wasm-bindgen --precise x
This is actually not needed, the current error message tells you how to fix this probably in a better way:
cargo update -p wasm-bindgen --precise x
This did not work for me, but maybe I forgot to run cargo build --target wasm32-unknown-unknown
.
Maybe a more detailed explanation of whats happening here may help:
- You build a Wasm file with
cargo build
, which contains thewasm-bindgen
dependency. - Then you run
wasm-bindgen-cli
over that Wasm file which produces a modified Wasm file and the JS shim.
If you change the wasm-bindgen
dependency, you have to recompile, otherwise you are running wasm-bindgen-cli
over the same old Wasm file with no changes.
Just for info. I got the same error because I forgot to update wasm-bindgen in Trunk.toml
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!
Ok I finally understand !
This error made me waste so much time :-(
If you use a cargo workspace, you can have a global Cargo.lock
AND a Cargo.lock
for each one of your workspace members.
Here is what happened in my case:
- I have a project that uses cargo workspaces. I have a workspace called
foo
- at one point, I forgot to include
foo
in the workspace members, so it got it's ownCargo.lock
- when I tried to build
foo
with trunk, I got an error saying there is a version mismatch -
cargo tree
guaranteed me that I used the rightwasm-bindgen
version, because it looked at the workspace level Cargo.toml - I wasn't able to fix the error with
cargo update
orcargo install
I would really appreciate if wasm-bindgen-cli
said "try to remove the Cargo.lock of your project members" if it detects you are in a workspace.
If you use a cargo workspace, you can have a global
Cargo.lock
AND aCargo.lock
for each one of your workspace members.
I don't think that's correct, a Cargo.lock
file in a project member directory should be ignored by Cargo if you are in a workspace. If not, I would say that's a Cargo bug.
I would really appreciate if
wasm-bindgen-cli
said "try to remove the Cargo.lock of your project members" if it detects you are in a workspace.
I think removing Cargo.lock
s is the wrong recommendation, because we just want wasm-bindgen
to be updated, removing it isn't always desirable nor is it required.
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.
I'm not an expert on Cargo, but I'm pretty sure it should only have a single path to the Cargo.lock file, the existence of a second Cargo.lock file should have no effect.
Could you upload a minimal reproducible example of this? It would be good to file a bug report of this at Cargo. Personally I was unable to reproduce it.
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!
I ran into the same issue and deleting the Cargo.lock from the members worked for me as well. It may be that Cargo needs to manage dependencies at the workspace level, and the existence of these additional files creates confusion/unexpected behavior in the wasm-bindgen or wasm-bindgen-cli tooling.
Neither wasm-bindgen
nor wasm-bindgen-cli
directly interacts with any Cargo.lock
file, so this shouldn't be the issue either.
Are you by any chance using wasm-pack
? Because after a quick search it seems wasm-pack
is actually trying to generate/read the Cargo.lock
content. If this is the case the root cause of this bug might be wasm-pack
.
I don't believe that I'm using wasm-pack
. Here's the project that was giving me problems.
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.