feat(desktop): add Windows desktop build support - #115
Conversation
Adds Windows packaging for the Electron desktop app, matching the existing macOS and Linux targets: - electron-builder `win` target (NSIS installer) + `nsis` config in apps/desktop/package.json, with `bundle:win` / `bundle:desktop:win` scripts mirroring the mac/linux ones - `release-windows` job in the Desktop Release workflow so tagged releases publish a Windows installer alongside macOS and Linux - `.gitattributes` enforcing LF so Windows clones (core.autocrlf=true) don't fail `pnpm check` on CRLF line endings - README / desktop README updated to reflect Windows support Native window controls on Windows already landed with Linux support (bholmesdev#100), so no renderer changes are needed.
HTML Apps use forward-slash asset URLs as their base, and workspace
file paths flow through the renderer as POSIX-style strings. On Windows
these arrive at the main process as "/C:/notes/..." with a leading
slash before the drive letter. path.resolve treats that as
drive-relative and prepends the current drive ("C:\C:\notes\..."),
which fails the granted-scope check, so the hubble-asset:// protocol
served nothing: HTML Apps rendered blank and local images 404'd.
Normalize the leading slash before a drive letter in resolvePath so
these paths resolve to a real Windows path. macOS/Linux are unaffected
(guarded on process.platform === "win32").
|
@saucy-tech is attempting to deploy a commit to the bholmesdev's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Draft for reference, happy to discuss the approach or hold/adjust. |
|
Fantastic, thanks for opening this! I'll test on a Windows install later tonight. |
|
Noticed in the screenshots that the window controls aren't visible in the top right. Is that just a limitation of your screenshot tool, or do we still need to render those? |
|
Oh yes windows controls are present, used chrome dev tools on those screenshots earlier. |
|
Heads up before you test. I did more testing today and hit a couple of pre-existing Windows path bugs (not from this PR's changes, but worth fixing here since it's about Windows working):
I'm fixing it by normalizing paths to forward slashes and will push to this PR with Windows test evidence (new file/folder at root + nested, rename, reveal, etc.). |
The renderer builds paths with forward slashes, but the main process returned native paths (backslash on Windows) from the directory listing, launch workspace path, folder/file pickers, watch events, and open-file events. The mix broke the sidebar's path helpers: relative- path stripping failed, so the workspace root and folders became phantom nested nodes (C: > Scratch > ...) and folder ids fed back into absolute- path joins produced doubled paths like "C:\ws/C:/ws/new-file.md" — breaking New file, New folder, and Reveal in File Explorer, and showing the workspace twice in the sidebar. Add toRendererPath() and apply it at every main->renderer path boundary so the renderer always sees forward slashes (collectWorkspaceFiles and the image-paste path already did this). resolvePath already normalizes them coming back. macOS/Linux are unaffected (path.sep is already "/").
|
Pushed the fix for the Windows path bugs from the heads-up above. Root cause: the main process returned native (backslash) paths for the directory listing, launch workspace path, folder/file pickers, watch events, and open-file events, while the renderer builds forward-slash paths. The mismatch broke the sidebar's relative/absolute path helpers — the workspace root turned into a phantom Fix: a small Verified on Windows 11 after the fix:
Rename is covered by the existing |
|
This is a great PR. Spent some time setting up a virtual machine on my Mac to run this on Windows. It exposed a couple other setup problems when using Windows on ARM64, so I committed some patches for that. I'm also tracking a separate issue #118 to pin the package manager and This feels good to merge to start getting Windows releases out there. Thanks for doing this! |
2 participants
Description
Adds Windows desktop build support, completing the macOS → Linux (#100) → Windows desktop lineage.
Closes #114
What's included:
electron-builderWindows NSIS target +nsisconfig inapps/desktop/package.json, plusbundle:win/bundle:desktop:winscripts that mirror the existing mac/linux ones.release-windowsjob indesktop-release.ymlso taggeddesktop-v*releases publish a Windows.exealongside the mac/linux artifacts (withshell: bashon the version-check/build steps forwindows-latest).resolvePathnow normalizes POSIX-style Windows asset paths (/C:/…). Without this,path.resolveproducedC:\C:\…, which failed the granted-scope check, so thehubble-asset://protocol served nothing — HTML Apps rendered blank and local Markdown images failed on Windows. macOS/Linux are unaffected (guarded onprocess.platform === "win32")..gitattributes(* text=auto eol=lf) so a Windows clone (core.autocrlf=true) doesn't check out CRLF and failpnpm check(Biome) on ~200 files. Verified near-no-op:git add --renormalize .changed 0 files (all tracked files are already LF).CHANGELOG.mdupdated.Native non-mac window controls already landed in #100, so no renderer/title-bar changes are needed here.
Type of Change
Testing
Manual Testing Details:
Built and tested on Windows 11 (Node 22, pnpm 10):
pnpm build(Biome + build-all + typecheck) andpnpm testboth green.pnpm bundle:desktop:winproducedhubble_0.1.14_x64.exe(NSIS); installed and launched.file-index.html,todo-demo.html) reading workspace files, and local Markdown images — all working after theresolvePathfix.Screenshots (Windows 11)
Markdown editor — rich rendering + local image
HTML App — workspace file index (reads
**/*.mdvia the file broker)HTML App — todo board (reads frontmatter from
todos/)Checklist