mirror of
https://github.com/pnpm/pnpm.git
synced 2026-03-28 12:01:37 -04:00
54c4fc4fb4
* fix: respect peer dep range in hoistPeers when preferred versions exist Previously, hoistPeers used semver.maxSatisfying(versions, '*') which picked the highest preferred version from the lockfile regardless of the peer dep range. This caused overrides that narrow a peer dep range to be ignored when a stale version existed in the lockfile. Now hoistPeers first tries semver.maxSatisfying(versions, range) to find a preferred version that satisfies the actual peer dep range. If none satisfies it and autoInstallPeers is enabled, it falls back to the range itself so pnpm resolves a matching version from the registry. * fix: only fall back to exact-version range for overrides, handle workspace: protocol - When no preferred version satisfies the peer dep range, only use the range directly if it is an exact version (e.g. "4.3.0" from an override). For semver ranges (e.g. "1", "^2.0.0"), fall back to the old behavior of picking the highest preferred version for deduplication. - Guard against workspace: protocol ranges that would cause semver.maxSatisfying to throw. - Add unit tests for hoisting deduplication and workspace: ranges. * fix: only apply range-constrained peer selection for exact versions The previous approach used semver.maxSatisfying(versions, range) for all peer dep ranges, which broke aliased-dependency deduplication — e.g. when three aliases of @pnpm.e2e/peer-c existed at 1.0.0, 1.0.1, and 2.0.0, range ^1.0.0 would pick 1.0.1 instead of 2.0.0. Now the range-aware logic only activates when the range is an exact version (semver.valid), which is the override case (e.g. "4.3.0"). Regular semver ranges fall back to picking the highest preferred version.