Skip to content

Pull upstream's fix for Windows installers that ship without a frontend - #17

Merged
QuicksilverSlick merged 1 commit into
mainfrom
fix/pull-upstream-frontenddist
Sep 11, 2026
Merged

Pull upstream's fix for Windows installers that ship without a frontend#17
QuicksilverSlick merged 1 commit into
mainfrom
fix/pull-upstream-frontenddist

Conversation

@QuicksilverSlick

Copy link
Copy Markdown
Owner

What

Cherry-picks block#7177 (dad5a3386, merged upstream on 5 Sep), which landed two days after our last upstream merge (#8, 3 Sep). The cherry-pick applied cleanly and includes upstream's updated test.

The bug it fixes

desktop/scripts/tauri-command.mjs passes Tauri the frontend directory as an absolute path in a --config override. frontendDist deserializes into an untagged enum whose first variant is a URL, and a Windows absolute path parses as one: C: becomes the URL scheme. Tauri then embeds zero assets, still exits 0, and the installed app opens to ERR_FILE_NOT_FOUND.

We hit this on 8 Sep with an installer that had no embedded frontend, and worked around it by skipping the wrapper: building into desktop/dist and calling pnpm exec tauri build directly. With this fix, scripts/build-windows-installer.bat should work as written again.

At the time we blamed backslashes and the space in the Windows username. That was wrong; the comment in upstream's fix explains the real mechanism.

Verification

  • Clean cherry-pick, no conflicts, authorship preserved.
  • CI runs the updated desktop/src/protectedFeatures/tauriCommand.test.mjs.
  • The next Windows installer will be built with the official script and checked the only reliable way: by counting the content-hashed files from desktop/dist/assets/ inside buzz-desktop.exe. The NSIS installer is LZMA-compressed, so grepping it proves nothing either way.

🤖 Generated with Claude Code

…ssets (block#7177)

## 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.

---------

Signed-off-by: Jeff Hedlund <jhedlund@gmail.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@QuicksilverSlick
QuicksilverSlick merged commit 418ae93 into main Sep 11, 2026
44 of 54 checks passed
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.

2 participants