bug: make _check-dx passes for any dx on PATH, not specifically Dioxus CLI #81

New issue

Closed

opened 2026-04-21 17:55:18 +00:00 by sameh-farouk · 0 comments

sameh-farouk commented

2026-04-21 17:55:18 +00:00

Member

Summary

make build-wasm (and make web / dev / desktop / build) fail cryptically on any machine where an unrelated executable named dx comes earlier on PATH than the Dioxus CLI.

Reproduced on a fresh Debian dev host with /usr/bin/dx from the OpenDX (data-visualization) package:

$ make build-wasm
Building WASM (debug)...
/usr/bin/dx : unrecognized parameter:  [1]
(use -help to get usage information)
make: *** [Makefile:110: build-wasm] Error 1

Same class of problem on macOS with Homebrew's Deno installed (/opt/homebrew/bin/dx from deno x).

Root cause

Makefile:_check-dx calls command -v dx, which is satisfied by any executable named dx, not specifically Dioxus CLI. When the first dx on PATH is something else (OpenDX, deno x shim, etc.), the preflight passes, build/serve targets invoke the wrong binary, and the failure surfaces several steps downstream as an unreadable error from a tool that has no idea what Dioxus CLI arguments mean.

Any developer provisioning a fresh box that happens to have OpenDX, Deno, or another dx in a system-managed directory will hit this.

Proposed fix

Two-part: resolve deterministically, then validate.

Resolve. Prefer ~/.cargo/bin/dx (where cargo install dioxus-cli installs) before falling back to whatever is first on PATH. Assign to a DX variable and use it everywhere.
Validate. After resolution, run $(DX) --version and grep for "dioxus" in the output. If the resolved binary is not Dioxus CLI, error out with the resolved path, the install command, and the PATH-order hint — not a downstream cryptic failure.

PR in flight: fix/dx-preflight-wrong-binary.

Scope

Affects web, dev, desktop, build, build-wasm targets — all of them go through _check-dx and then invoke bare dx. All migrated to $(DX) in the PR.

### Summary `make build-wasm` (and `make web` / `dev` / `desktop` / `build`) fail cryptically on any machine where an unrelated executable named `dx` comes earlier on `PATH` than the Dioxus CLI. Reproduced on a fresh Debian dev host with `/usr/bin/dx` from the OpenDX (data-visualization) package: ``` $ make build-wasm Building WASM (debug)... /usr/bin/dx : unrecognized parameter: [1] (use -help to get usage information) make: *** [Makefile:110: build-wasm] Error 1 ``` Same class of problem on macOS with Homebrew's Deno installed (`/opt/homebrew/bin/dx` from `deno x`). ### Root cause `Makefile:_check-dx` calls `command -v dx`, which is satisfied by **any** executable named `dx`, not specifically Dioxus CLI. When the first `dx` on `PATH` is something else (OpenDX, `deno x` shim, etc.), the preflight passes, build/serve targets invoke the wrong binary, and the failure surfaces several steps downstream as an unreadable error from a tool that has no idea what Dioxus CLI arguments mean. Any developer provisioning a fresh box that happens to have OpenDX, Deno, or another `dx` in a system-managed directory will hit this. ### Proposed fix Two-part: resolve deterministically, then validate. 1. **Resolve.** Prefer `~/.cargo/bin/dx` (where `cargo install dioxus-cli` installs) before falling back to whatever is first on `PATH`. Assign to a `DX` variable and use it everywhere. 2. **Validate.** After resolution, run `$(DX) --version` and grep for "dioxus" in the output. If the resolved binary is not Dioxus CLI, error out with the resolved path, the install command, and the PATH-order hint — not a downstream cryptic failure. PR in flight: `fix/dx-preflight-wrong-binary`. ### Scope Affects `web`, `dev`, `desktop`, `build`, `build-wasm` targets — all of them go through `_check-dx` and then invoke bare `dx`. All migrated to `$(DX)` in the PR.