* 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.
* refactor: factor out a `getRealNameAndSpec` function
* fix: handle npm aliases without a bare specifier in `unwrapPackageName`
* Fix formatting in unwrapPackageName.ts
* refactor: store link values before converting to references
* fix: use .sort() without localeCompare
https://github.com/pnpm/pnpm/pull/8128#discussion_r1614031566
> Nit, but you probably just want to call sort without a comparison
> function; these are already strings and locale compare is not a good
> comparison for anything but human readable strings since it will
> differ on different people's machines based on their language setting.
> I've hit this too many times before for code gen.
* feat: configure meta-updater to write test/tsconfig.json files
* fix: relative imports for __typings__
* chore: `pnpm run meta-updater`
* fix: explicitly use test/tsconfig.json for ts-jest
close#7444
Peer dependencies of peer dependencies are now resolved correctly. When peer dependencies have peer dependencies of their own, the peer dependencies are grouped with their own peer dependencies before being linked to their dependents.
For instance, if `card` has `react` in peer dependencies and `react` has `typescript` in its peer dependencies, then the same version of `react` may be linked from different places if there are multiple versions of `typescript`. For instance:
```
project1/package.json
{
"dependencies": {
"card": "1.0.0",
"react": "16.8.0",
"typescript": "7.0.0"
}
}
project2/package.json
{
"dependencies": {
"card": "1.0.0",
"react": "16.8.0",
"typescript": "8.0.0"
}
}
node_modules
.pnpm
card@1.0.0(react@16.8.0(typescript@7.0.0))
node_modules
card
react --> ../../react@16.8.0(typescript@7.0.0)/node_modules/react
react@16.8.0(typescript@7.0.0)
node_modules
react
typescript --> ../../typescript@7.0.0/node_modules/typescript
typescript@7.0.0
node_modules
typescript
card@1.0.0(react@16.8.0(typescript@8.0.0))
node_modules
card
react --> ../../react@16.8.0(typescript@8.0.0)/node_modules/react
react@16.8.0(typescript@8.0.0)
node_modules
react
typescript --> ../../typescript@8.0.0/node_modules/typescript
typescript@8.0.0
node_modules
typescript
```
In the above example, both projects have `card` in dependencies but the projects use different versions of `typescript`. Hence, even though the same version of `card` is used, `card` in `project1` will reference `react` from a directory where it is placed with `typescript@7.0.0` (because it resolves `typescript` from the dependencies of `project1`), while `card` in `project2` will reference `react` with `typescript@8.0.0`.
A new setting added for symlinking [injected dependencies](https://pnpm.io/package_json#dependenciesmetainjected) from the workspace, if their dependencies use the same peer dependencies as the dependent package. The setting is called `dedupe-injected-deps`
When dedupe-peer-dependents is enabled (default), use the path to
determine compatibility.
When multiple dependency groups can be deduplicated, the
latter ones are sorted according to number of peers to allow them to
benefit from deduplication.
close#6605
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
