[BUG] new wasm-pack version v0.13.0 breaking build

[nulltrope]

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?

0.0.18

Describe the bug

A new version of wasm-pack was published yesterday which seems to have broken worker-build.

Ultimately, the wasm-pack issue should be addressed/fixed in that project (it has already been reported among a few other issues, on the GH: rustwasm/wasm-pack#1405) however I was a bit surprised that this repository was installing an unpinned/unversioned binary from another project, which can lead to unexpected behavior especially when no action or version change was taken on the user's part.

In the meantime, I am manually installing a known-working version of wasm-pack manually before invoking worker-build.

That being said, I think it would be a good idea for this project to pin the binaries it installs to specific versions, to avoid unexpected behavior when said upstream binaries publish new versions.

Steps To Reproduce

1. Install with cargo install -q --git https://github.com/cloudflare/workers-rs --rev 12e011ad9fa2eddd73759908d9d54b5d54dd07ee --bin worker-build (version shouldn't matter, just using mine as an example)
2. Run the binary we just installed with worker-build --release
3. See the following error:

error: failed to run custom build command for `libz-ng-sys v1.1.15`
Caused by:
  process didn't exit successfully: `/tmp/cargo-installD20ZUK/release/build/libz-ng-sys-9558847959953b2c/build-script-build_zng` (exit status: 101)
  --- stdout
  CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
  CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_x86_64-unknown-linux-gnu = None
  CMAKE_GENERATOR_x86_64_unknown_linux_gnu = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_x86_64-unknown-linux-gnu = None
  CMAKE_PREFIX_PATH_x86_64_unknown_linux_gnu = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_x86_64-unknown-linux-gnu = None
  CMAKE_x86_64_unknown_linux_gnu = None
  HOST_CMAKE = None
  CMAKE = None
  running: cd "/tmp/cargo-installD20ZUK/release/build/libz-ng-sys-02f76757fe2d8ec1/out/build" && CMAKE_PREFIX_PATH="" "cmake" "/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libz-ng-sys-1.1.15/src/zlib-ng" "-DBUILD_SHARED_LIBS=OFF" "-DZLIB_COMPAT=OFF" "-DZLIB_ENABLE_TESTS=OFF" "-DWITH_GZFILEOP=ON" "-DCMAKE_INSTALL_PREFIX=/tmp/cargo-installD20ZUK/release/build/libz-ng-sys-02f76757fe2d8ec1/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release"
  --- stderr
  thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cmake-0.1.50/src/lib.rs:1098:5:
  failed to execute command: No such file or directory (os error 2)
  is `cmake` not installed?
  build script failed, must exit now
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `wasm-pack v0.13.0`, intermediate artifacts can be found at `/tmp/cargo-installD20ZUK`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
Error: installation of wasm-pack exited with status exit status: 101

[LuisDuarte1]

Had the same problem, solved it by installing CMake in your host machine. It seems that some dependency of wasm-pack requires it.

[nulltrope]

Had the same problem, solved it by installing CMake in your host machine. It seems that some dependency of wasm-pack requires it.

Correct, installing cmake will resolve the issue, however previous versions of wasm-pack did not require cmake to build, and having dependencies change with no change to the version of workers-rs you are pinned to is still concerning.

[nulltrope]

Alright well the immediate issue (reliance on cmake) should be resolved once this gets merged upstream rustwasm/wasm-pack#1407 however I do still think it's worth considering pinning to a specific version of wasm-pack that gets cargo install'd by this project to avoid any future issues like this.