wasm-bindgen
wasm-bindgen copied to clipboard
rustwasm
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.74Currently 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!
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.
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-bindgendependency. - Then you run
wasm-bindgen-cliover 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
fooin the workspace members, so it got it's ownCargo.lock - when I tried to build
foowith trunk, I got an error saying there is a version mismatch cargo treeguaranteed me that I used the rightwasm-bindgenversion, because it looked at the workspace level Cargo.toml- I wasn't able to fix the error with
cargo updateorcargo 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.lockAND aCargo.lockfor 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-clisaid "try to remove the Cargo.lock of your project members" if it detects you are in a workspace.
I think removing Cargo.locks 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.