Skip to content

chore(dev): rebuild client on change for desktop dev on Windows - #4459

Closed
CN-liuzhiyang wants to merge 1 commit into
getpaseo:mainfrom
CN-liuzhiyang:chore/desktop-dev-win-rebuild
Closed

chore(dev): rebuild client on change for desktop dev on Windows#4459
CN-liuzhiyang wants to merge 1 commit into
getpaseo:mainfrom
CN-liuzhiyang:chore/desktop-dev-win-rebuild

Conversation

@CN-liuzhiyang

Copy link
Copy Markdown

Linked issue

N/A

Type of change

  • Enhancement

Reasoning

npm run dev watch-builds @getpaseo/protocol and @getpaseo/client, but the Windows desktop dev launcher (packages/desktop/scripts/dev.ps1) never rebuilt them. After a git pull that touched the protocol, the desktop app ran against stale dist output and failed in ways that looked like app bugs. Separately, Hyper-V/WSL on Windows reserves TCP port blocks that commonly include 8081, so Metro fell back to a random port on every restart and dev browser storage (hosts, layout) was lost each time.

Goals

  • dev.ps1 fingerprints protocol/client sources (HEAD plus a hash of the working-tree diff against it) against the last desktop dev build and reruns build:client only when that changed.
  • dev.ps1 honours a preset EXPO_PORT instead of always auto-picking from 8081-8085.
  • Document both behaviours and the reserved-port check (netsh interface ipv4 show excludedportrange protocol=tcp) in docs/development.md.
  • Add a desktop-win service entry to paseo.json so Paseo-managed worktrees can launch Windows desktop dev.
  • Ignore lefthook-local.yml (machine-specific hook overrides).

Non-goals

  • No change to dev.sh or the POSIX desktop dev flow.
  • No live file watcher; the fingerprint is checked once per launch.

QA

  • Windows 11, npm run dev:win:desktop: first launch rebuilds build:client and writes packages/desktop/.dev/build-client.fingerprint; relaunching with no protocol/client changes prints the skip line; editing a file under packages/protocol/src triggers a rebuild on the next launch.
  • setx EXPO_PORT 8181 then relaunch: Metro binds 8181 across restarts.
  • This PR is a rebase of a commit that was previously bundled into feat(app): browse full commit history in a History tab #4141 and is the launcher the author uses daily on Windows. It was not re-run end to end after the rebase; npm run typecheck and npm run lint pass on the rebased branch. npm run format:check reports only AGENTS.md / packages/server/AGENTS.md, which are unformatted on main and untouched here.

Checklist

  • Plugin changes follow the SDK import boundaries (n/a)
  • One focused change
  • npm run typecheck passes
  • npm run lint passes
  • npm run format passes (for the files in this PR)
  • QA evidence
  • Tests added or updated where it made sense (shell launcher; no test harness)

@greptile-apps

greptile-apps Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR improves Windows desktop development startup behavior.

  • Rebuilds the protocol/client distributions when the launcher fingerprint changes.
  • Preserves a preset EXPO_PORT and otherwise selects an available Metro port.
  • Adds a Paseo-managed Windows desktop service.
  • Documents Windows port reservations and desktop development behavior.
  • Ignores machine-specific Lefthook overrides.

Confidence Score: 4/5

The PR is not yet safe to merge because the Windows launcher can skip a required rebuild for untracked source files, and the explicit documentation requirement remains unsatisfied.

The fingerprint still uses git diff HEAD, which omits untracked protocol or client source files, so a newly added module can leave the consumed distributions stale. It also still includes the repository-wide HEAD SHA, causing unnecessary rebuilds after unrelated commits. The development documentation continues to record implementation-specific paths, fingerprint construction, and marker details despite the repository directive against documentation that merely restates code. The two manually resolved threads do not remain outstanding.

Files Needing Attention: packages/desktop/scripts/dev.ps1, docs/development.md

Important Files Changed

Filename Overview
packages/desktop/scripts/dev.ps1 Adds conditional client rebuilding and configurable Metro-port selection; the existing untracked-source and repository-wide-HEAD fingerprint findings remain outstanding.
docs/development.md Documents desktop build and port behavior; the unresolved repository-rule finding about restating implementation remains outstanding.
paseo.json Adds the Windows desktop managed-service command; its previous daemon-port thread was manually resolved.
.gitignore Ignores the machine-specific Lefthook override file.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    Start[Launch Windows desktop development] --> Main[Build Electron main process]
    Main --> Fingerprint[Compute client build fingerprint]
    Fingerprint --> Changed{Fingerprint changed?}
    Changed -->|Yes| Build[Build protocol and client distributions]
    Build --> Save[Save fingerprint]
    Changed -->|No| Skip[Reuse existing distributions]
    Save --> Port
    Skip --> Port{EXPO_PORT preset?}
    Port -->|Yes| Preserve[Use configured port]
    Port -->|No| Select[Select from 8081 through 8085]
    Preserve --> Desktop[Start desktop development]
    Select --> Desktop
Loading

Reviews (2): Last reviewed commit: "chore(dev): rebuild client on change and..." | Re-trigger Greptile

)
$ClientBuildMarker = "$DesktopDir\.dev\build-client.fingerprint"
$HeadSha = (git -C $RootDir rev-parse HEAD).Trim()
$WorkingDiff = git -C $RootDir diff HEAD -- $ClientBuildPaths

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Untracked Sources Skip Rebuild

The fingerprint uses git diff HEAD, which does not include untracked files. If a developer adds a protocol or client module and imports it from outside these fingerprinted paths, the fingerprint remains unchanged, build:client is skipped, and Metro resolves against stale dist output where the new module does not exist.

Comment on lines +28 to +31
$HeadSha = (git -C $RootDir rev-parse HEAD).Trim()
$WorkingDiff = git -C $RootDir diff HEAD -- $ClientBuildPaths
$WorkingDiffHash = if ($WorkingDiff) { ($WorkingDiff -join "`n" | git -C $RootDir hash-object --stdin).Trim() } else { "clean" }
$CurrentFingerprint = "$HeadSha|$WorkingDiffHash"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Unrelated Commits Trigger Rebuilds

The fingerprint includes the repository-wide HEAD SHA, so every commit or branch switch changes it even when protocol and client inputs are identical. Pulling changes limited to the app, server, or documentation therefore reruns the client build, contrary to the stated source-change-only behavior.

Comment thread paseo.json
Comment thread docs/development.md
Comment thread docs/development.md
Comment on lines +34 to +40
Desktop dev doesn't watch-build `@getpaseo/protocol`/`@getpaseo/client` the way
`npm run dev` does. `packages/desktop/scripts/dev.ps1` instead fingerprints
their sources (current `HEAD` plus a hash of the working-tree diff against it)
against the fingerprint from the last desktop dev build, stored in
`packages/desktop/.dev/build-client.fingerprint`, and only reruns `build:client`
when that fingerprint changed — so a `git pull` that touches protocol picks up
a rebuild automatically, and repeat restarts with no relevant changes skip it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Documentation Restates Implementation

This section records the exact input paths, Git fingerprint construction, marker-file location, and branch condition. That violates the repository directive not to document logic that merely restates code because such prose drifts from the implementation. Keep the user-facing behavior and rationale here, but this repository requirement must be satisfied before merging.

Context Used: CLAUDE.md (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

…top dev on Windows

Desktop dev didn't watch-build protocol/client like `npm run dev` does, so
stale dist output for those packages went unnoticed. Fingerprint their
sources against the last desktop dev build and rebuild only when they
changed. Also documents the Windows Hyper-V/WSL reserved-port gotcha and
adds a `desktop-win` paseo.json service entry.
@CN-liuzhiyang
CN-liuzhiyang force-pushed the chore/desktop-dev-win-rebuild branch from caf6886 to 889a7c1 Compare September 8, 2026 07:24
@boudra

boudra commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Closing for now: this needs Windows launcher evidence that changed and newly added client/protocol sources reach the running app, and that the new managed service uses its assigned daemon port. Please reopen with that evidence.

@boudra boudra closed this Sep 8, 2026
@boudra

boudra commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

Please disregard the earlier invitation to reopen with evidence. This PR remains closed unless I explicitly follow up. You don't need to resubmit this PR or provide further QA evidence.

Please read the updated PR policy. For now, I'm automatically closing feature PRs so I can focus more time on bug fixes and core improvements. Focused bug-fix PRs with a clear reproduction and QA are still welcome. The previous guide already asked contributors to submit only if they were comfortable with closure, and explained that unsolicited PRs could be closed without a detailed review.

For feature ideas, please start in GitHub Discussions and share your workflow: what you're trying to do, how you do it today, and where Paseo gets in the way. If there's already a discussion about it, join in and share your use case. I'll periodically review discussions for highly requested workflows and use that feedback to shape the roadmap.

I'll periodically look through closed PRs and choose which contributions to take forward, whether solicited or unsolicited. I may reopen a PR, including one closed by mistake, or use it as a reference for my own implementation, with attribution either way.

There are hundreds of PRs alongside ongoing development. I can't commit to reviewing every submission, providing individual feedback or giving timelines.

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