Add Windows support for CLI updates via npm#12877
Add Windows support for CLI updates via npm#12877AlexS935 wants to merge 1 commit intogitbutlerapp:masterfrom
Conversation
…ling The `but update install` command was previously unix-only (#[cfg(unix)]), leaving Windows users with no self-update mechanism. When the CLI is installed via npm on Windows, npm's rename operation fails with EBUSY because the running process locks the package directory. This adds Windows support that: - Detects npm installations by checking if the exe is under node_modules - Spawns a detached batch script that waits for the CLI to exit before running `npm install -g <package>`, avoiding the EBUSY file lock - For non-npm Windows installations, provides download instructions - Extracts cache invalidation into a shared helper https://claude.ai/code/session_01TBAMrb7RTK9884TPorXCTP
|
@claude is attempting to deploy a commit to the GitButler Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c17c7d6960
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let version_suffix = match target.as_deref() { | ||
| Some(version) => format!("@{version}"), | ||
| None => "@latest".to_string(), | ||
| }; |
There was a problem hiding this comment.
Preserve channel when no npm target is provided
When but update install is run on Windows npm installs without an explicit target, this branch always uses @latest instead of deriving the channel from the current build (unlike the Unix path, which auto-detects release vs nightly). In the nightly channel this causes users to be switched to stable on their next update, which contradicts the command’s documented default behavior and can silently change the installed track.
Useful? React with 👍 / 👎.
|
Thanks a lot for giving it a shot! Let's use this PR as forum for discussion how Windows updates should be supported, and what alternatives to NPM were considered. In any case, this PR isn't mergable yet and may need time, so I am putting it back into draft. |
🧢 Changes
#[cfg(unix)]guards from theinstallcommand to enable it on all platformsinstall()function to dispatch to platform-specific implementations:install_unix(): Handles Linux/macOS installations (existing logic)install_windows(): New Windows-specific handler with npm detectiondetect_npm_package()to identify npm-based installations on Windows by checking fornode_modulesin the executable path or thenpm_package_nameenvironment variableinstall_via_npm()to perform npm updates on Windows by spawning a detached batch script that waits for the current process to exit before runningnpm install -g, avoiding EBUSY file lock errorsinvalidate_update_cache()helper function to reduce code duplication☕️ Reasoning
Previously, the
installcommand was only available on Unix platforms. This change extends update support to Windows users with npm-based installations.On Windows, npm cannot rename package directories while the current process (running from that directory) holds file locks. The solution spawns a detached updater script that waits for the CLI process to exit before proceeding with the npm update, eliminating the EBUSY error.
For non-npm Windows installations, the command provides helpful download instructions pointing users to the official downloads page.
The refactoring improves maintainability by separating platform-specific logic into dedicated functions and extracting the cache invalidation logic into a reusable helper.
https://claude.ai/code/session_01TBAMrb7RTK9884TPorXCTP