Support Windows #99

New issue

deadstyle · 2026-10-09T11:32:43-05:00

deadstyle commented

2026-10-09 11:32:43 -05:00

Problem

lazyforge ships Linux and macOS binaries only. A Windows user is coming soon, so it needs a Windows build and a way to install it.

Acceptance criteria

Each release publishes windows/amd64 and windows/arm64 archives alongside the existing four, with their lines in checksums.txt. (design.md → Install and updates)
On Windows, one PowerShell command (irm .../install.ps1 | iex) picks the right binary, verifies its checksum, installs to %LOCALAPPDATA%\Programs\lazyforge, and adds that directory to the user's PATH. Running it again upgrades in place. (design.md → Install: "one command ... verifies its checksum ... running it again upgrades in place")
The startup update check works on Windows: it offers the newer release, downloads and verifies the Windows archive, replaces lazyforge.exe, and starts the new version. A failed start rolls back to the old one. (design.md → Updates)
Config and state files live under the user config dir (%AppData%\lazyforge) on Windows; XDG overrides still win.
Opening an item in the browser works on Windows.
token_cmd works on Windows.
$EDITOR comments work on Windows; with $EDITOR unset the fallback is notepad, not vi.
README's Install section documents Windows and drops "Windows isn't supported yet"; design.md's Install line mentions the Windows command.
make check stays green on Linux and also cross-compiles the Windows targets.

Plan

Makefile / release: add windows/amd64, windows/arm64; package those as lazyforge_<tag>_windows_<arch>.zip containing lazyforge.exe.
install.ps1 (new), plus a check in scripts/ that the zip asset names match what make release produces.
internal/update: asset extension and entry name by GOOS (.zip + lazyforge.exe on windows); extraction via archive/zip.
cmd/lazyforge/update.go: re-exec by syscall.Exec on Unix; on Windows start the new exe as a child with stdio attached, wait, and exit with its code (build-tagged files, no runtime GOOS branching around syscall.Exec).
internal/config/paths.go: windows uses os.UserConfigDir() for both files, as darwin does.
internal/ui/actions.go: openBrowser uses rundll32 url.dll,FileProtocolHandler on windows; editor fallback notepad on windows.
internal/config/token.go: cmd /C on windows, sh -c elsewhere.
make check: add GOOS=windows go build and go vet.

Context

Checked 2026-10-09: GOOS=windows go build ./cmd/lazyforge already succeeds, so the gaps are behavioral. syscall.Exec compiles on windows but always errors, so the update would apply, fail to restart, and roll back (cmd/lazyforge/update.go:65).
internal/update/update.go:116 hard-codes .tar.gz; extract looks for an entry named lazyforge.
internal/config/paths.go:25 special-cases darwin only; others get ~/.config.
internal/ui/actions.go:50 only knows xdg-open/open; :306 falls back to vi.
internal/config/token.go:25 runs sh -c.
Windows allows renaming a running exe, so the exe→exe.old swap in Apply still works.

Out of scope

winget/scoop/Chocolatey packages, code signing, Windows CI runners (cross-compile only), terminal-image protocol support on Windows.

## Problem lazyforge ships Linux and macOS binaries only. A Windows user is coming soon, so it needs a Windows build and a way to install it. ## Acceptance criteria - Each release publishes `windows/amd64` and `windows/arm64` archives alongside the existing four, with their lines in `checksums.txt`. *(design.md → Install and updates)* - On Windows, one PowerShell command (`irm .../install.ps1 | iex`) picks the right binary, verifies its checksum, installs to `%LOCALAPPDATA%\Programs\lazyforge`, and adds that directory to the user's `PATH`. Running it again upgrades in place. *(design.md → Install: "one command ... verifies its checksum ... running it again upgrades in place")* - The startup update check works on Windows: it offers the newer release, downloads and verifies the Windows archive, replaces `lazyforge.exe`, and starts the new version. A failed start rolls back to the old one. *(design.md → Updates)* - Config and state files live under the user config dir (`%AppData%\lazyforge`) on Windows; XDG overrides still win. - Opening an item in the browser works on Windows. - `token_cmd` works on Windows. - `$EDITOR` comments work on Windows; with `$EDITOR` unset the fallback is `notepad`, not `vi`. - README's Install section documents Windows and drops "Windows isn't supported yet"; design.md's Install line mentions the Windows command. - `make check` stays green on Linux and also cross-compiles the Windows targets. ## Plan - `Makefile` / `release`: add `windows/amd64`, `windows/arm64`; package those as `lazyforge_<tag>_windows_<arch>.zip` containing `lazyforge.exe`. - `install.ps1` (new), plus a check in `scripts/` that the zip asset names match what `make release` produces. - `internal/update`: asset extension and entry name by GOOS (`.zip` + `lazyforge.exe` on windows); extraction via `archive/zip`. - `cmd/lazyforge/update.go`: re-exec by `syscall.Exec` on Unix; on Windows start the new exe as a child with stdio attached, wait, and exit with its code (build-tagged files, no runtime GOOS branching around `syscall.Exec`). - `internal/config/paths.go`: windows uses `os.UserConfigDir()` for both files, as darwin does. - `internal/ui/actions.go`: `openBrowser` uses `rundll32 url.dll,FileProtocolHandler` on windows; editor fallback `notepad` on windows. - `internal/config/token.go`: `cmd /C` on windows, `sh -c` elsewhere. - `make check`: add `GOOS=windows go build` and `go vet`. ## Context - Checked 2026-10-09: `GOOS=windows go build ./cmd/lazyforge` already succeeds, so the gaps are behavioral. `syscall.Exec` compiles on windows but always errors, so the update would apply, fail to restart, and roll back (`cmd/lazyforge/update.go:65`). - `internal/update/update.go:116` hard-codes `.tar.gz`; `extract` looks for an entry named `lazyforge`. - `internal/config/paths.go:25` special-cases darwin only; others get `~/.config`. - `internal/ui/actions.go:50` only knows `xdg-open`/`open`; `:306` falls back to `vi`. - `internal/config/token.go:25` runs `sh -c`. - Windows allows renaming a running exe, so the exe→exe.old swap in `Apply` still works. ## Out of scope winget/scoop/Chocolatey packages, code signing, Windows CI runners (cross-compile only), terminal-image protocol support on Windows.

deadstyle added the

feature

label

2026-10-09 11:32:49 -05:00

deadstyle referenced this issue

2026-10-09 11:32:51 -05:00

docs: lead the README with the install script #100

deadstyle added the

sonnet

label

2026-10-09 11:51:19 -05:00

deadstyle referenced this issue from a commit