How do I get rid of the "unstable use of buildTrunkPackage" warning?

[antifuchs]

I'm using crane to package a trunk-built WASM package in my web app server, and that works really well (the wasm-cli version pinning notwithstanding). However, whenever I evaluate the system configuration that deploys the server, I get this warning:

trace: evaluation warning: Unstable usage of buildTrunkPackage!
The version of the tool `wasm-bindgen-cli` (Package used during compilation)
must match the version of the `wasm-bindgen` (Rust library, check your Cargo.lock),
buildTrunkPackage now requires the argument wasm-bindgen-cli:
buildTrunkPackage {
 wasm-bindgen-cli = pkgs.wasm-bindgen-cli.override {
 version = "0.2.84";
 hash = "sha256-0rK+Yx4/Jy44Fw5VwJ3tG243ZsyOIBBehYU54XP/JGk=";
 cargoHash = "sha256-vcpxcRlW1OKoD64owFF6mkxSqmNrvY+y3Ckn5UwEQ50=";
 };
 ...
}

...but I am passing the wasm-bindgen-cli argument, with the equivalent package. Is there a way to get rid of that warning somehow, or is that a bug in crane's buildTrunkPackage?

[antifuchs]

I just pushed up the code that results in that warning: https://github.com/lz-bookmarks/lz/blob/main/flake.nix#L119-L125 - I'm pretty sure I am not doing anything wrong there, is it because the ? lib.warn value always gets evaluated?

[ipetkov]

Hi @antifuchs I think you are missing some parentheses when overriding args:

(Without the parens, Nix will essentially evaluate the equivalent of (buildTrunkPackage wasmArgs) // { ... } instead of buildTrunkPackage (wasmArgs // { ... }) )

diff --git a/flake.nix b/flake.nix
index c040400..2ebab00 100644
--- a/flake.nix
+++ b/flake.nix
@@ -115,14 +115,13 @@
             // {
               doCheck = false;
             });
-          ui =
-            craneLib.buildTrunkPackage wasmArgs
+          ui = craneLib.buildTrunkPackage (wasmArgs
             // {
               pname = "lz-ui-wasm";
               cargoArtifacts = cargoArtifactsWasm;
               wasm-bindgen-cli = pkgs.wasm-bindgen-cli;
               stripPhase = "";
-            };
+            });
         in
           rustPlatform.buildRustPackage {
             pname = "lz";

[antifuchs]

...oof. Yep, ensuring that the operations happen in the right order is exactly what fixes this issue. Thanks for the kind response!