Repository navigation
feat(cli): hyperframes open hands the project to the app on Windows and Linux too - #6484
Merged
Merged
Conversation
Contributor
Edit accuracy: accurate 271 (base branch 271), smooth 142 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 1 important · 0 nits · head aa12b154
I checked the app side. hyperframes-internal#2687 is merged, and folderInArgv is still on main: it handles both the first launch and second-instance, and it requires an absolute path, which resolveProject gives. The NSIS InstallDir is $LOCALAPPDATA\Programs\<name>, which matches desktopApps. CI passed on this head.
- important: Linux
.debinstalls are not found.desktopAppsonly readslauncher.json, and the app writes it only whenAPPIMAGEis set (folderArg.mjswriteLauncher). The.deb, which is what/studio/downloadserves to Linux browsers by default (osOf→deb), installs to/opt/<pkg>/<name>with a/usr/binsymlink and never writes that file. So a.debuser who runshyperframes openis told "The HyperFrames desktop app isn't installed on this computer" and gets the AppImage link. Those users already got the download before this PR, so this is not a regression, but the PR's "works on Linux" covers AppImage only. Follow-up: also look for/opt/<pkg>/<name>(or/usr/bin/<pkg>) on Linux, or have the app writelauncher.jsonfor the.debtoo.
— Claude
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
hyperframes open <dir>(and the app linerenderandpreviewprint) now works on Windows and Linux.HANDOFF_READY, which was true only on macOS, is true everywhere. The folder is passed on the app's command line, the path the CLI already took on those platforms once the gate opened.Why
Windows and Linux CLI users were shown the app download but their project never opened in it: the gate kept every surface on "download" and wrote no hand-off. The app already takes a folder on its command line on both platforms (macOS sends
open-file), so the gate no longer protects anyone.Why under 100 lines
Windows launch fix, separate failure (the project never opens in the app), ships alone; the app already takes the folder, so nothing else has to land with it.
Tests
Two new cases in
desktopApp.test.ts, one per platform, that callopenInDesktopwith noreadyoverride: the Windows install path and the Linux AppImage each receive the folder and the result isopened: true. Both fail with the gate closed (2 failed, 28 passed) and pass here (39 indesktopAppanddesktopRoutes).Not run against a real Windows or Linux app install.