Option to stop Dioxus CLI from ignoring tooling in PATH

[crabdancing]

Feature Request

As it stands, the dx utility is bundled with / automatically fetches its own wasm-bindgen-cli that it uses over the environment one. This is certainly useful on imperative systems, but on declarative ones like Nix, it seems actively harmful to get something to work reliably.

E.g., I see this message:

Caused by:
    0: Failed to generate wasm-bindgen bindings
    1:

       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.99
            this binary schema version: 0.2.97

I add this to my dev environment:

            (pkgs.wasm-bindgen-cli.override {
              version = "0.2.99";
              hash = "sha256-1AN2E9t/lZhbXdVznhTcniy+7ZzlaEp/gwLEAucs6EA=";
              cargoHash = "sha256-DbwAh8RJtW38LJp+J9Ht8fAROK9OabaJ85D9C/Vkve4=";
            })

My Nix development environment is now correctly pinning the wasm-bindgen-cli version:

wasm-bindgen -V
wasm-bindgen 0.2.99

But dx ignores this and stubbornly keeps using the wrong version.

Implement Suggestion

It should be possible to pass a simple flag, or environment variable, to override Dioxus CLI's behavior, so that rather than trying to handle which dependencies are used, it just trusts the environment (PATH, etc) to be correct. Perhaps a flag like --use-local-tooling? This ideally would stop any attempt to automatically fetch any external tooling, and instead simply look for it in PATH, and error immediately if needed but not present.

That way, reproducible build processes like Nix, Docker, and whatnot, can simply pin their own environment at a specific version, and have it just work.

This would (maybe?) obviate PR #3442, fix issue #3083, and pave the way toward better reproducible CI for all Dioxus apps.

[DogeDark]

The version conflict error - that's caused by the wasm-bindgen our CLI installs? If so, that needs fixed asap. Our CLI (v0.6.1) should install the wasm-bindgen version that Cargo reports your project needs. I haven't had issues with this, but perhaps a more complex project setup could cause it to fail.

I agree with needing a way to override wasm-bindgen and other systems the CLI uses.

[crabdancing]

IDK if that's the case. I am using dioxus-cli pinned from NixOS master (this looks to be 0.6.0 as of this writing). If the behavior changed as of the latest minor version bump, that might be why it's failing like this. I'll write a Nix expression to update it to the latest dioxus-cli, and report back on that matter.

perhaps a more complex project setup could cause it to fail.

I am currently testing against the demo project that dx init gives you. So it is probably not an edge case.

On the subject of being able to actually control which wasm-bindgen version is being used, does the PATH method seem reasonable? On the Nix side of things -- almost any method can be made to work -- flags, PATH, specific env vars like DIOXUS_WASM_BINDGEN_CLI_PATH. I can give examples of working Nix code for any option you might choose to implement. I just figured that taking from PATH was the closest thing to standard, covered the most use cases, and fits pretty well with people's expectations.

Edit:

Some of the other Nix users here have spotting an issue with dx assuming rustup will be in the environment, and its absence causing some of the code in dx to not even bother trying to fetch the proper wasm-bindgen-cli version. (See #3083)

I went ahead and tried out their rustup shell shim workaround, but it doesn't seem to be working, either via 0.6.0, or 0.6.1 (tried both nix build github:j4ger/dioxus#packages.x86_64-linux.dx and via cargo install dioxus-cli). (It fails with a vague error. See error log.)

Regardless, this is kind of off topic for the scope of this feature request.

It should also be emphasized that this 'simple' behavior mode I'm proposing probably should not make any assumptions about whether e.g. rustup is present, as tools like it are strictly imperative. What I'm proposing here, for clarity, is some way of completely opting out of dx's complicated attempts to help the user deal with toolchain dependencies altogether.

If that were done, it would be relatively trivial to then get it to build in nix envs, both in impure shells for quick development/prototyping, and strict build environments.

[j4ger]

IDK if that's the case. I am using dioxus-cli pinned from NixOS master (this looks to be 0.6.0 as of this writing). If the behavior changed as of the latest minor version bump, that might be why it's failing like this. I'll write a Nix expression to update it to the latest dioxus-cli, and report back on that matter.

perhaps a more complex project setup could cause it to fail.

I am currently testing against the demo project that dx init gives you. So it is probably not an edge case.

On the subject of being able to actually control which wasm-bindgen version is being used, does the PATH method seem reasonable? On the Nix side of things -- almost any method can be made to work -- flags, PATH, specific env vars like DIOXUS_WASM_BINDGEN_CLI_PATH. I can give examples of working Nix code for any option you might choose to implement. I just figured that taking from PATH was the closest thing to standard, covered the most use cases, and fits pretty well with people's expectations.

Edit:

Some of the other Nix users here have spotting an issue with dx assuming rustup will be in the environment, and its absence causing some of the code in dx to not even bother trying to fetch the proper wasm-bindgen-cli version. (See #3083)

I went ahead and tried out their rustup shell shim workaround, but it doesn't seem to be working, either via 0.6.0, or 0.6.1 (tried both nix build github:j4ger/dioxus#packages.x86_64-linux.dx and via cargo install dioxus-cli). (It fails with a vague error. See error log.)

Regardless, this is kind of off topic for the scope of this feature request.

It should also be emphasized that this 'simple' behavior mode I'm proposing probably should not make any assumptions about whether e.g. rustup is present, as tools like it are strictly imperative. What I'm proposing here, for clarity, is some way of completely opting out of dx's complicated attempts to help the user deal with toolchain dependencies altogether.

If that were done, it would be relatively trivial to then get it to build in nix envs, both in impure shells for quick development/prototyping, and strict build environments.

That dx derivative is simply the latest dx as the one in nixpkgs is not new enough for the wasm-bindgen auto-install feature. You might need to use the web devShell to make it work (something like nix develop github:j4ger/dioxus#web. That said, I'm pretty new to nix and it may not be the proper way to implement this.

Anyway, a better solution to this from the code level will be beneficial.