[LiPu-jpg]

When an npm installation is retried in a profile that already pins an old exact version, pnpm add <name> can retain that selection even if latest has moved. In LiPu-jpg/Openwrite#142 the Hub 2.2.3 command was add dsh-openwrite, and DSH rejected the selected 0.2.25 although the published 0.2.28 supports the reported host. The retained-version condition was reproduced with a local registry using both pnpm 9.15.9 and 12.9.1.

Pass explicit add intent into npmInstallTargetOf and request @latest for bare registry names during install as well as update. Preserve the supply-chain-gated pinned installSpec, already-versioned specs, Git/tarball sources, global npm operations, and removal targets.

Validation: all 8 install-target tests passed; the complete test suite passed with 232 passed and 2 existing skips; client/server/test type checks passed. The full suite was run with GIT_CONFIG_GLOBAL=/dev/null and GIT_CONFIG_NOSYSTEM=1 so the real invalid-proxy probe uses the test's proxy instead of the developer machine's Git proxy configuration.

Related report: LiPu-jpg/Openwrite#142 .

[dshplugin]

Thanks @LiPu-jpg — merged.

We reproduced the reasoning and checked the edges before merging: the retained-version behaviour matches what you described, pinned still wins over @latest, and versioned/tagged specs, tarballs, git sources, global installs and removals all stay untouched. Local run: 234 tests, 232 pass, 0 fail.

One style-only follow-up landed in 2322306 (early returns in npmInstallTargetOf, Chinese test naming to match the rest of the suite) — no behaviour change.

Heads-up on one side effect: dsh profiles run minimumReleaseAge=1440, so pkg@latest now surfaces ERR_PNPM_NO_MATURE_MATCHING_VERSION for packages published less than 24h ago, where a bare add pkg used to silently install the previous mature version. The hub already classifies that and shows the exact retry time, and it matches the update path, so we accept the trade-off — a silent downgrade is the same class of bug you fixed.