dioxus
dioxus copied to clipboard
Cargo.lock for dioxus-cli is outdates
Problem
Some packaging tools like nix use Cargo.lock to pick up versions of the dependencies. Currently dioxus-cli Cargo.lock uses 0.2.93 webasm-bindgen but rest of Dioxus uses 0.2.95 version of bindgen.
Steps To Reproduce
Steps to reproduce the behavior:
- Use packager using Cargo.lock
- Create example
- Run
dx serve
Expected behavior
Sample application runs
Actual behaviour
dx fails due to mismatch of versions
Environment:
- Dioxus version: 0.5.7
- Rust version: 1.80.0
- OS info: Nix
- App platform: all
I can reproduce this as well on my machine
flake.nix
{
inputs = {
nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
flake-utils.url = "github:numtide/flake-utils";
};
outputs =
{
self,
nixpkgs,
flake-utils,
}:
flake-utils.lib.eachDefaultSystem (
system:
let
pkgs = import nixpkgs { inherit system; };
in
{
devShell =
with pkgs;
mkShell {
buildInputs = [
cargo
rustc
rustfmt
rustPackages.clippy
dioxus-cli
lld
];
};
}
);
}
Enviroment
$ dx --version && cargo --version && rustc --version && uname -r
dioxus 0.5.7
cargo 1.81.0 (2dbb1af80 2024-08-20)
rustc 1.81.0 (eeb90cda1 2024-09-04) (built from a source tarball)
6.11.4-arch1-1
Output of `dx serve`
$ dx serve
👑 Build done.
thread 'main' panicked at src/builder.rs:188:14:
called `Result::unwrap()` on an `Err` value:
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.95
this binary schema version: 0.2.93
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 0.2.93
don't forget to recompile your wasm file! Alternatively, you can update the
binary with:
cargo install -f wasm-bindgen-cli --version 0.2.95
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!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2024-10-23T03:15:36.576163Z ERROR dioxus_cli::builder: Bindgen build failed: Any { .. }
2024-10-23T03:15:37.796421Z ERROR dioxus_cli::builder: Failed to update wasm-bindgen: Output {
status: ExitStatus(
unix_wait_status(
25856,
),
),
stdout: "",
stderr: " Updating crates.io index\nerror: failed to select a version for the requirement `wasm-b
indgen = \"^0.2.95\"`\ncandidate versions found which didn't match: 0.2.93\nlocation searched: crates.io
index\nrequired by package `web-sys v0.3.72`\n ... which satisfies dependency `web-sys = \"^0.3.61\"
` (locked to 0.3.72) of package `dioxus-fullstack v0.5.6`\n ... which satisfies dependency `dioxus-fu
llstack = \"^0.5.6\"` (locked to 0.5.6) of package `dioxus v0.5.6`\n ... which satisfies dependency `
dioxus = \"^0.5\"` (locked to 0.5.6) of package `masterbot-dx v0.1.0 (/home/el/Projects/masterbot-dx)`\n
",
}
Error: 🚫 Serving project failed:
Caused by:
Build Failed: WASM bindgen build failed!
This is probably due to the Bindgen version, dioxus-cli is using `0.2.93` which is not compatible wi
th your crate.
Please reinstall the dioxus cli to fix this issue.
You can reinstall the dioxus cli by running `cargo install dioxus-cli --force` and then rebuild your
project
I had this on ArchLinux but running cargo install --force dioxus-cli rebuilt it and it no longer complains about the 0.2.93 and 0.2.95 mismatch.
Found the exact same problem on my nixos system, haven't found any declarative solutions yet
We keep the wasm bindgen version unlocked so that it updates to match other dependencies in the ecosystem that pull in the latest version of wasm bindgen like web-sys. You can fix this issue by reinstalling the CLI with cargo install --force dioxus-cli (without --locked)
We keep the wasm bindgen version unlocked so that it updates to match other dependencies in the ecosystem that pull in the latest version of wasm bindgen like web-sys. You can fix this issue by reinstalling the CLI with
cargo install --force dioxus-cli(without--locked)
It should be added that you also have to add $HOME/.cargo/bin to path
It seems that dioxus-cli v0.6.1 introduces a mechanism of auto downloading the correct version of wasm-bindgen, but I couldn't make it work no matter how. I even tried manually downloading wasm-bindgen binaries and putting them into ~/.local/share/dioxus/wasm-bindgen/ (btw the directory was present but empty before), but the dx serve command still produces the following:
20:52:42 [dev] Build completed successfully - output location: "/home/j4ger/Documents/pele/tmp/target/server-dev/tmp" 20:52:42 [dev] Collecting assets ... 20:52:42 [dev] Assembling app bundle 20:52:42 [dev] Running wasm-bindgen 20:52:42 [dev] Setting builder to failed state 20:52:42 [dev] Build failed: Other(Failed to write main executable
Caused by: 0: Failed to generate wasm-bindgen bindings 1: No such file or directory (os error 2))
Also, I'm curious if someone is able to setup a full flake-based devShell for dioxus, as all the solutions available now seem to be reliant on cargo install.
It seems that
dioxus-cli v0.6.1introduces a mechanism of auto downloading the correct version ofwasm-bindgen, but I couldn't make it work no matter how. I even tried manually downloadingwasm-bindgenbinaries and putting them into~/.local/share/dioxus/wasm-bindgen/(btw the directory was present but empty before), but thedx servecommand still produces the following:20:52:42 [dev] Build completed successfully - output location: "/home/j4ger/Documents/pele/tmp/target/server-dev/tmp" 20:52:42 [dev] Collecting assets ... 20:52:42 [dev] Assembling app bundle 20:52:42 [dev] Running wasm-bindgen 20:52:42 [dev] Setting builder to failed state 20:52:42 [dev] Build failed: Other(Failed to write main executable Caused by: 0: Failed to generate wasm-bindgen bindings 1: No such file or directory (os error 2))
Also, I'm curious if someone is able to setup a full flake-based devShell for dioxus, as all the solutions available now seem to be reliant on
cargo install.
@j4ger i'm no expert, but i have tried in the previous versions with the following flake and did not work:
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
rust-overlay.url = "github:oxalica/rust-overlay";
flake-utils.url = "github:numtide/flake-utils";
};
outputs = {
nixpkgs,
rust-overlay,
flake-utils, ...
}: flake-utils.lib.eachDefaultSystem (system:
let
overlays = [ (import rust-overlay)];
pkgs = import nixpkgs {
inherit system overlays;
};
toolchain = pkgs.rust-bin.fromRustupToolchainFile ./rust-toolchain.toml;
custom-wasm-bindgen-cli = pkgs.wasm-bindgen-cli.override {
version = "0.2.95";
hash = "sha256-DDdu5mM3gneraM85pAepBXWn3TMofarVR4NbjMdz3r0=";
cargoHash = "sha256-birrg+XABBHHKJxfTKAMSlmTVYLmnmqMDfRnmG6g/YQ=";
};
custom-dioxus-cli = pkgs.dioxus-cli.overrideAttrs (oldAttrs: rec {
version = "0.6.0";
src = pkgs.fetchCrate {
pname = "dioxus-cli";
version = "0.6.0-alpha.0";
hash = "sha256-XbX/sg9HPKhH+VN6x4wMhPW9fZw+3jap6l8oNsCB0HQ=";
};
cargoHash = "";
});
in
{
devShells.default = pkgs.mkShell {
nativebuildInputs = [
pkgs.openssl
];
shellHook = ''
export PKG_CONFIG_PATH=${pkgs.openssl.dev}/lib/pkgconfig
'';
packages = [
pkgs.zlib
# pkgs.wasm-bindgen-cli
# custom-wasm-bindgen-cli
# pkgs.dioxus-cli
# custom-dioxus-cli
toolchain
pkgs.nodejs_23
] ++ (with pkgs.nodePackages; [ prettier tailwindcss ]);
};
}
);
}
./rust-toolchain.toml being :
[toolchain]
channel = "stable"
profile = "default"
targets = ["wasm32-unknown-unknown", "aarch64-apple-darwin", "x86_64-unknown-linux-gnu"]
i have been using this and upgrading it forever with also using direnv:
./.envrc being :
watch_file *.nix rust-toolchain.toml
export WEBKIT_DISABLE_COMPOSITING_MODE=1
export PATH=$HOME/.cargo/bin:$PATH
# export OPENSSL_DIR=$(dirname $(whereis openssl | awk '{print $2}')) # doesn't work since openssl binary path is not the same as the one required
use flake
i should later integrate these exports into my flake
I hope this helps someone find a way to make it fully work without the need for manually having to use cargo or just make its life easier for using dioxus.
It seems that
dioxus-cli v0.6.1introduces a mechanism of auto downloading the correct version ofwasm-bindgen, but I couldn't make it work no matter how. I even tried manually downloadingwasm-bindgenbinaries and putting them into~/.local/share/dioxus/wasm-bindgen/(btw the directory was present but empty before), but thedx servecommand still produces the following:20:52:42 [dev] Build completed successfully - output location: "/home/j4ger/Documents/pele/tmp/target/server-dev/tmp" 20:52:42 [dev] Collecting assets ... 20:52:42 [dev] Assembling app bundle 20:52:42 [dev] Running wasm-bindgen 20:52:42 [dev] Setting builder to failed state 20:52:42 [dev] Build failed: Other(Failed to write main executable Caused by: 0: Failed to generate wasm-bindgen bindings 1: No such file or directory (os error 2))
Also, I'm curious if someone is able to setup a full flake-based devShell for dioxus, as all the solutions available now seem to be reliant on
cargo install.@j4ger i'm no expert, but i have tried in the previous versions with the following flake and did not work:
{ inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; rust-overlay.url = "github:oxalica/rust-overlay"; flake-utils.url = "github:numtide/flake-utils"; }; outputs = { nixpkgs, rust-overlay, flake-utils, ... }: flake-utils.lib.eachDefaultSystem (system: let overlays = [ (import rust-overlay)]; pkgs = import nixpkgs { inherit system overlays; }; toolchain = pkgs.rust-bin.fromRustupToolchainFile ./rust-toolchain.toml; custom-wasm-bindgen-cli = pkgs.wasm-bindgen-cli.override { version = "0.2.95"; hash = "sha256-DDdu5mM3gneraM85pAepBXWn3TMofarVR4NbjMdz3r0="; cargoHash = "sha256-birrg+XABBHHKJxfTKAMSlmTVYLmnmqMDfRnmG6g/YQ="; }; custom-dioxus-cli = pkgs.dioxus-cli.overrideAttrs (oldAttrs: rec { version = "0.6.0"; src = pkgs.fetchCrate { pname = "dioxus-cli"; version = "0.6.0-alpha.0"; hash = "sha256-XbX/sg9HPKhH+VN6x4wMhPW9fZw+3jap6l8oNsCB0HQ="; }; cargoHash = ""; }); in { devShells.default = pkgs.mkShell { nativebuildInputs = [ pkgs.openssl ]; shellHook = '' export PKG_CONFIG_PATH=${pkgs.openssl.dev}/lib/pkgconfig ''; packages = [ pkgs.zlib # pkgs.wasm-bindgen-cli # custom-wasm-bindgen-cli # pkgs.dioxus-cli # custom-dioxus-cli toolchain pkgs.nodejs_23 ] ++ (with pkgs.nodePackages; [ prettier tailwindcss ]); }; } ); }./rust-toolchain.toml being :
[toolchain] channel = "stable" profile = "default" targets = ["wasm32-unknown-unknown", "aarch64-apple-darwin", "x86_64-unknown-linux-gnu"]i have been using this and upgrading it forever with also using direnv:
./.envrc being :
watch_file *.nix rust-toolchain.toml export WEBKIT_DISABLE_COMPOSITING_MODE=1 export PATH=$HOME/.cargo/bin:$PATH # export OPENSSL_DIR=$(dirname $(whereis openssl | awk '{print $2}')) # doesn't work since openssl binary path is not the same as the one required use flakei should later integrate these exports into my flake
I hope this helps someone find a way to make it fully work without the need for manually having to use cargo or just make its life easier for using dioxus.
Thank you for this, I need to fix our nix flake but am/was unsure how to go about it.
After digging into the source of dioxus cli I found out the reason why dx skipped installing the proper wasm-bindgen: the trigger for installing wasm-bindgen comes after the logic of toolchain verification, as my nix devShell does not rely on rustup, the verification function bails out in the middle, thus skipping the download. After adding rustup to the devShell all problems were gone. I'll try to come up with a simplified flake.nix and maybe create a pull request shortly after.
Also, just for the clarification, the current flake.nix in the repo only creates a devShell for developing dioxus itself, but I don't think it's meant for developers using dioxus as a framework, as it does not setup dx and other toolchain for you. I hope I can come up with a proper solution for this.
After digging into the source of
dioxus cliI found out the reason whydxskipped installing the properwasm-bindgen: the trigger for installingwasm-bindgencomes after the logic of toolchain verification, as my nix devShell does not rely onrustup, the verification function bails out in the middle, thus skipping the download. After addingrustupto the devShell all problems were gone. I'll try to come up with a simplifiedflake.nixand maybe create a pull request shortly after.Also, just for the clarification, the current
flake.nixin the repo only creates a devShell for developingdioxusitself, but I don't think it's meant for developers usingdioxusas a framework, as it does not setupdxand other toolchain for you. I hope I can come up with a proper solution for this.
Would there be any way of doing this without the use of rustup? it is not best for usage in flakes
After digging into the source of
dioxus cliI found out the reason whydxskipped installing the properwasm-bindgen: the trigger for installingwasm-bindgencomes after the logic of toolchain verification, as my nix devShell does not rely onrustup, the verification function bails out in the middle, thus skipping the download. After addingrustupto the devShell all problems were gone. I'll try to come up with a simplifiedflake.nixand maybe create a pull request shortly after.Also, just for the clarification, the current
flake.nixin the repo only creates a devShell for developingdioxusitself, but I don't think it's meant for developers usingdioxusas a framework, as it does not setupdxand other toolchain for you. I hope I can come up with a proper solution for this.Would there be any way of doing this without the use of rustup? it is not best for usage in flakes
I've created a PR here: https://github.com/DioxusLabs/dioxus/pull/3442
While it is under review, you can tryout my fork first. I made a mockup rustup script to bypass the verification and it works for now.
Although the "nix-way" to do this would be to include a build of wasm-bindgen in the flake as well so that all artifacts used are deterministic, I can't come up with a better way to do so other than mangling with the $XDG_STATE_HOME envvars. As it would create potential issues for library users, I left that part unchanged and rely on dx's own installation process.