fix(desktop): keep packaged frontendDist relative so Windows embeds assets

[jhedlund]

Root cause

tauri-command.mjs points frontendDist at a mkdtemp directory so concurrent OSS/internal packages cannot overwrite each other's assets. On Windows that is an absolute path with a drive letter.

FrontendDist is an untagged serde enum whose first variant is Url(Url), and C:\Users\... is a valid WHATWG URL with scheme c:, so serde selects Url. tauri-codegen then does:

FrontendDist::Url(_url) => Default::default(),   // embed nothing

A missing directory panics with a clear message; a URL is silent. The build exits 0 and produces an installable app with no frontend assets, which boots to ERR_FILE_NOT_FOUND in the WebView.

Linux and macOS are unaffected — /tmp/... has no scheme, so it falls through to Directory.

This affects every Windows build that goes through pnpm tauri build, including release.yml's NSIS job and windows-canary.yml.

Fix

Pass the path relative to the config's own directory. tauri-codegen resolves frontendDist with config_parent.join(path), so a relative path reaches the same directory and cannot parse as a URL. When the temp directory is on another drive there is no relative form, so the scratch root is created beside the config instead.

BUZZ_PROTECTED_BUILD_OUTPUT still receives the absolute path, and cleanup is unchanged.

Testing

tauriCommand.test.mjs asserted against the value it had just been handed, so it could not observe this. Its fake CLI also resolved frontendDist against the process cwd, which is not what Tauri does.

• Fake CLI now resolves against the config directory, matching config_parent.join(path).
• New case asserts the packaged frontendDist is not absolute and does not parse as a URL. The absolute check is what fails on Linux/macOS, so the regression stays covered on every platform.
• Verified the new case fails on the unpatched wrapper and passes with the fix; the two existing cases pass either way.
• Desktop suite: 5844 passed. useDocumentVisible has a pre-existing load-dependent flake that also reproduces on an unmodified checkout.
• Biome check clean on both files.

Verified end to end by rebuilding the Windows NSIS installer: embedded asset keys in buzz-desktop.exe went from 0 to 490, and the app launches.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 4365883151698cd30e31cf4091629543b61c2478...363d9251d732f8f8cfd223fe99451af2024a2c6c.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 363d9251d732f8f8cfd223fe99451af2024a2c6c to authorize a new review.
Any previous review applies only to its recorded range.

[jhedlund]

Introduced with #6902

This fixes the Windows build (ref #2388 windows support)

[wesbillman]

Review by Brain on behalf of Wes (wesbillman).

Please have the fake build write through the producer environment path, while keeping the read below on the config-resolved consumer path. Currently, changing the wrapper's production frontendDist to dist/wrong-subdir still passes all three tests: this fake writes and reads the same wrong location.

I verified the suggestion below in an isolated checkout at 1f80098bb9: valid production code passes 3/3; the wrong-directory mutation fails. The existing relative/non-URL assertions also fail when the absolute-path regression is restored.

Suggested change

	mkdirSync(output, { recursive: true });
	writeFileSync(path.join(output, "variant.txt"), process.env.VITE_BUZZ_BESTIE);
	const producer = process.env.BUZZ_PROTECTED_BUILD_OUTPUT;
	mkdirSync(producer, { recursive: true });
	writeFileSync(path.join(producer, "variant.txt"), process.env.VITE_BUZZ_BESTIE);

[jhedlund]

Applied in 363d925, with one deviation from the suggestion: I added a
three-line comment above it explaining why the write and the read use
different paths, so it doesn't read as pointless indirection and get
collapsed back later.

Confirmed the finding reproduces here before changing anything. With the
old fixture, repointing the wrapper's override at
path.join(relativeTo(invocationRoot), "wrong-subdir") still passed 3/3.
With the change it's 0/3. The absolute-path regression this PR exists for
is still caught by the relative/non-URL case, on its own assertion.

One caveat worth your opinion: the wrong-directory mutation now fails as
Error: wrapper exited 1 — the fake's readFileSync throwing ENOENT —
rather than a named assertion. It's a genuine failure, but not a
self-explaining one. Happy to give it a clearer shape if you'd prefer.

[wesbillman]

Thanks for this!

[jhedlund]

@wesbillman thanks for the review!

[jhedlund]

@wesbillman Thanks again for looking at this PR so quickly. I don't have write access so I can't merge, is that something you do or it gets picked up automatically or what?

[jhedlund]

@wesbillman I think the new 0.5.22 release is probably broken on Windows without this merged.

I haven't confirmed it yet because I have some agents mid-thought right now on my local Buzz, but looking at the size of the file (~42MB) it's near the exact one that broke on my dev that made me push this PR. Normal was ~53MB, with ~42MB the windows assets are missing. As soon as I can I'll confirm on my Windows desktop

[jhedlund]

No need for me to confirm it locally, #7334 opened with people seeing the issue