-
Notifications
You must be signed in to change notification settings - Fork 134
fix: resolve the install from the running binary; make upgrade failures diagnosable (#1305) #1306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
saravmajestic
merged 11 commits into
main
from
fix/install-detection-and-upgrade-diagnostics
Sep 18, 2026
Merged
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
e98ba6d
fix: resolve the install from the running binary; make upgrade failur…
saravmajestic b9a769c
fix: correct .local/bin regression and revert collateral reformat (#1…
saravmajestic d0cac98
fix: address review findings — non-global layouts, yarn on Windows, b…
saravmajestic 1ef5916
fix: establish ownership before acting; stop leaking diagnostics; cor…
saravmajestic f228cb2
fix: mark the uninstall choco-branch removal (#1305)
saravmajestic 6ee55b6
fix: detect the unscoped npm wrapper; redact the success path too (#1…
saravmajestic 2708fc8
fix: resolve install ownership from the manager; refuse destructive a…
saravmajestic 40779c5
fix: mark the two remaining altimate_change additions (#1305)
saravmajestic 5d99234
fix: one resolved identity; report the upgrade that actually happened…
saravmajestic c6e9c51
fix: don't misreport relocated-binary upgrades; make identity memoiza…
saravmajestic cc57ee1
fix: verify only against exact targets; bound ownership to our own pa…
saravmajestic File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CRITICAL —
altimate upgrade latest(or any non-exact-version target) always misreports a successful upgrade as failedWhen the user supplies an explicit
targetargument, it is used verbatim —Installation.latest()is only called whenargs.targetis absent. Soaltimate upgrade latestsetstarget = "latest"and that literal string flows intoInstallation.upgrade(method, target), which passes it straight to the package manager (npm install -g altimate-code@latest, etc.). npm/pnpm/bun correctly resolve"latest"to a concrete version and install it successfully — but the post-upgrade verification (index.ts:1069) then compares the actual resolved version against the literal string"latest":normalize("0.12.0") !== normalize("latest")is alwaystrue— there is no code path that ever makes these equal. The result: everyaltimate upgrade latestsucceeds at the package-manager level and is then unconditionally reported as a failure, with a misleading "the package manager reported success but wrote somewhere other than the running executable" message. The same applies to any dist-tag (beta,next) or semver range (^0.12.0) passed as an explicit target.This is not probabilistic or environment-dependent like the Homebrew Cellar-cleanup finding from last round — it is deterministic and 100% reproducible. It also breaks the "already up to date, skip" fast path a few lines above (
Installation.VERSION === target), which likewise can never match a tag/range string.altimate upgrade latestmirrors a convention users already know fromnpm install -g pkg@latest, so this is a realistic, not contrived, way to trigger it.Suggestion: Resolve
targetto a concrete version before it's used for anything comparison-sensitive:(Or, more robustly, have the post-upgrade verification treat a non-semver
targetas "cannot verify against this value" rather than as a hard mismatch — falling back to the existing "ran but reported no comparable version" branch instead of thecontradictedbranch.)(Independently found by MiniMax M2.7 with this precise line-level trace; Qwen 3.6 flagged the general shape — comparing raw
targetagainst resolved version — in less precise form. Claude confirmed the exact mechanism by re-reading this ternary's control flow.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in cc57ee1. This one was unambiguous and I should have caught it when I wrote the check —
targetis whatever the caller passed, and I never asked what values it can take before comparing a resolved version against it.Verification now only contradicts when the target is an exact version:
A dist-tag or range is logged as "not verified against it" rather than failed — comparing a resolved version to an unresolved specifier is not a check, so the honest outcome is "unverifiable", the same category already used for a binary that runs but prints nothing.
I did not resolve the specifier up front instead (calling
latest()when the target is not exact). It would restore a real check, but each manager resolves tags and ranges by its own rules, so we would be re-implementing their resolution to grade their work — and getting that subtly wrong reintroduces exactly this class of false failure.Tests cover
latest,betaand^0.12.0not failing, plus an exact target that genuinely does not match afterwards still failing, so the check has not simply been weakened into a no-op.