Repository navigation
fix(cli): only name a shadowing install whose manager can move it - #7499
Conversation
A project-local node_modules/.bin/hyperframes can shadow plain npx hyperframes, but npm install -g never updates it. Classify the shadowing copy like the running one: global installs keep their manager's command, project-local installs get the project's own manager (from its lockfile), and unknown layouts stay quiet. The command pins the release the npx copy is running.
jrusso1020
left a comment
There was a problem hiding this comment.
Reviewed at 5403738d2e44aabc6cedefcd98d807c86fe5a24f.
The #7488 Nit is resolved. installAt classifies the shadowing path itself, while runningInstall retains its plugin override and prior classification order. Project-local candidates reuse the lockfile-aware updateCommandFor; unknown/workspace layouts no longer receive a guessed global command. The update targets the resolved run's version rather than a moving latest.
Validation: 180 tests passed across installerDetection, attendedTerminal, auth/login, updateCheck and autoUpdate. Replayed the earlier real-filesystem symlink repro against base and head: base suggests npm install -g hyperframes@latest; head correctly suggests npm install hyperframes@0.9.29. The new Bun-lockfile and unknown-layout tests also pass. Independent adversarial source pass found no new defect. No package installation/update was executed by these probes.
Need: yes · Size: ok · Reuse: shared installAt and updateCommandFor · Simpler: already minimal · Structure: fine (checked running-install and reverse consumers; no split)
Risk: low - reuses existing classification and command generation for a read-only notice.
Verdict: APPROVE
Reasoning: The follow-up closes the misleading project-local update suggestion without changing the existing installer behavior.
Reviewed by hf-review.
Follow-up to #7488, from the review nit there.
shadowingInstallnamed any olderhyperframeson PATH and suggestednpm install -gfor anything it couldn't classify. A project-localnode_modules/.bin/hyperframesalso shadows plainnpx hyperframes, but a global install never moves it.Now the shadowing copy is classified the same way as the running one (
runningInstallandinstallAtshare the code):bun add hyperframes@<v>,pnpm add …,yarn add …,npm install …). This reusesupdateCommandFor, whichdoctorandupgradealready use._meta.updateAvailablerule still pins the run.The command now names the release the npx copy is running instead of
latest, so a project install's command doesn't fall back tonpx hyperframes@latest.Tests: two new
shadowingInstallcases. A project-local install withbun.lockgetsbun add; an unknown layout getsnull.