fix(build): make npm run tauri pass the correct TAURI_CONFIG to the CLI#77
Open
vidaunited wants to merge 1 commit into
Open
fix(build): make npm run tauri pass the correct TAURI_CONFIG to the CLI#77vidaunited wants to merge 1 commit into
vidaunited wants to merge 1 commit into
Conversation
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fresh checkouts fail
tauri devandtauri buildon macOS with tauri-build's feature-allowlist error:Traced the root cause by wrapping
cargoin a shim that logs every env var it receives from tauri-cli 2.11.2:TAURI_CONFIGis 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'sTAURI_CONFIG=falsefallback — needed so plaincargo build/cargo testmatch the intentionally featureless basetauridependency (seetools/phase-c/validate-config.mjs) — silently leaks into real CLI runs instead.This is worse than a build-script lint: the same
TAURI_CONFIGenv var is also read bygenerate_context!()to build the config embedded in the compiled binary, so a realtauri buildrelease would silently ship with the macOS private-API window styling disabled — no error, just wrong runtime behavior.Fix
tools/tauri-run.mjscomputes the correctmacOSPrivateApivalue fromtauri.macos.conf.json(not hardcoded, stays correct if that value changes) and setsTAURI_CONFIGexplicitly before spawning the real CLI, winning over the.cargo/config.tomlfallback (cargo's[env]never overrides an already-set var). Uses Node'sspawnSyncrather than shell env-var syntax so it works identically on the Windows/Ubuntu Parallels CI legs, which invoke the samenpm run tauri -- build --no-bundleentrypoint..cargo/config.tomlis untouched: itsfalsefallback still correctly servescargo test/cargo buildand phase-c's release-build step, which don't exercisegenerate_context!()'s runtime path.Test plan
Verified cold (fresh clone,
rm -rf target) on macOS:npm run tauri dev— starts and builds cleanlycargo test --manifest-path src-tauri/Cargo.toml --lib— 272 passednpm run buildnpm run build:phase-c— 6/6 passedPHASE_C_STRICT_TAURI=1 npm run build:phase-c— 7/7 passed, including the realtauri build --no-bundlepath