Skip to content

fix(build): make npm run tauri pass the correct TAURI_CONFIG to the CLI#77

Open
vidaunited wants to merge 1 commit into
msitarzewski:mainfrom
vidaunited:fix/tauri-config-env-leak
Open

fix(build): make npm run tauri pass the correct TAURI_CONFIG to the CLI#77
vidaunited wants to merge 1 commit into
msitarzewski:mainfrom
vidaunited:fix/tauri-config-env-leak

Conversation

@vidaunited

Copy link
Copy Markdown

Summary

Fresh checkouts fail tauri dev and tauri build on macOS with tauri-build's feature-allowlist error:

The `tauri` dependency features on the `Cargo.toml` file does not match the allowlist defined under `tauri.conf.json`.

Traced the root cause by wrapping cargo in a shim that logs every env var it receives from tauri-cli 2.11.2: TAURI_CONFIG is never set for the CLI's build step, contrary to the assumption in .cargo/config.toml's comment ("the Tauri CLI sets its own fully-merged TAURI_CONFIG, which therefore wins"). That file's TAURI_CONFIG=false fallback — needed so plain cargo build/cargo test match the intentionally featureless base tauri dependency (see tools/phase-c/validate-config.mjs) — silently leaks into real CLI runs instead.

This is worse than a build-script lint: the same TAURI_CONFIG env var is also read by generate_context!() to build the config embedded in the compiled binary, so a real tauri build release would silently ship with the macOS private-API window styling disabled — no error, just wrong runtime behavior.

Fix

tools/tauri-run.mjs computes the correct macOSPrivateApi value from tauri.macos.conf.json (not hardcoded, stays correct if that value changes) and sets TAURI_CONFIG explicitly before spawning the real CLI, winning over the .cargo/config.toml fallback (cargo's [env] never overrides an already-set var). Uses Node's spawnSync rather than shell env-var syntax so it works identically on the Windows/Ubuntu Parallels CI legs, which invoke the same npm run tauri -- build --no-bundle entrypoint.

.cargo/config.toml is untouched: its false fallback still correctly serves cargo test/cargo build and phase-c's release-build step, which don't exercise generate_context!()'s runtime path.

Test plan

Verified cold (fresh clone, rm -rf target) on macOS:

  • npm run tauri dev — starts and builds cleanly
  • cargo test --manifest-path src-tauri/Cargo.toml --lib — 272 passed
  • npm run build
  • npm run build:phase-c — 6/6 passed
  • PHASE_C_STRICT_TAURI=1 npm run build:phase-c — 7/7 passed, including the real tauri build --no-bundle path

Fresh checkouts fail 'tauri dev' and 'tauri build' on macOS with
tauri-build's feature-allowlist error. Traced the root cause by wrapping
cargo in a shim that logs every env var it receives from tauri-cli
2.11.2: TAURI_CONFIG is never set for the CLI's build step, contrary to
the assumption in .cargo/config.toml's comment ('the Tauri CLI sets its
own fully-merged TAURI_CONFIG, which therefore wins'). That file's
TAURI_CONFIG=false fallback — needed so plain 'cargo build'/'cargo test'
match the intentionally featureless base tauri dependency (see
tools/phase-c/validate-config.mjs) — silently leaks into real CLI runs
instead.

This is worse than a build-script lint: the same TAURI_CONFIG env var is
also read by generate_context!() to build the config embedded in the
compiled binary, so a real 'tauri build' release would silently ship
with the macOS private-API window styling disabled — no error, just
wrong runtime behavior.

Fix: tools/tauri-run.mjs computes the correct macOSPrivateApi value from
tauri.macos.conf.json (not hardcoded, stays correct if that value
changes) and sets TAURI_CONFIG explicitly before spawning the real CLI,
winning over the config.toml fallback (cargo's [env] never overrides an
already-set var). Uses Node's spawnSync rather than shell env-var syntax
so it works identically on the Windows/Ubuntu Parallels CI legs, which
invoke the same 'npm run tauri -- build --no-bundle' entrypoint.
.cargo/config.toml is untouched: its false fallback still correctly
serves cargo test/cargo build and phase-c's release-build step, which
don't exercise generate_context!()'s runtime path.

Verified cold: tauri dev, cargo test --lib (272 passed), npm run build,
npm run build:phase-c (6/6), and PHASE_C_STRICT_TAURI=1 npm run
build:phase-c (7/7, including the real 'tauri build --no-bundle' path).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant