Wasm-pack ignoring cargo lockfile when building on github actions

[gcfcow]

I created a continuous deployment workflow to deploy a game I wrote. However, it is not working because wasm-pack ignores the cargo lockfile, resulting in incompatible dependencies being pulled in. It is clear the lockfile is being ignored because when building with wasm-pack it pulls serde 1.0.115 versus the one in the lockfile v1.0.92.

You can see the incorrect serde version in the failed output here: https://github.com/GiantCowFilms/InterPlanetGame/runs/1011063024?check_suite_focus=true), the cargo lock file is here: https://github.com/GiantCowFilms/InterPlanetGame/blob/master/Cargo.lock

I attempted to fix the problem by building the crate for the wasm target before using wasm-pack with cargo build (hoping that something would get cached causing wasm-pack to obey). That build did obey the cargo lock file, but unfortunately wasm-pack also ignored the cache.

I have been unable to reproduce this problem locally (using both WSL and Windows 10). Does anyone know why wasm-pack ignores the cargo lock file and how to force it to use it. I was unable to find the relevant information in the wasm-pack documentation.

[alice]

I don't know, but you can specify the exact version in the Cargo.toml using the equals sign.

serde = "=1.0.92"

Please submit a bug-report to libraries that are not backwards compatible despite not releasing a breaking change.

[gcfcow]

I guess pinning stuff is an option for a work around. That being said, I would prefer if my CI used the Cargo.lock file, as there can always be surprises.

The reason for the breakage between minor versions has to do with the nightly toolchain I am using for the project. I started using async stuff before async was stabilized, and now my project is stuck on a particular nightly version with particular dependencies until I can find the time to upgrade to to stable async. So I don't think this is a bug in the libraries.