Zoltan Kochan
a5effe488d
The Rust CLI computed peer-dependency issues during resolution and then dropped them on the floor: every call site passed `peer_issues_sink: None`, and the only other consumer was a `tracing::warn!` the reporter never shows. `strictPeerDependencies` was parsed and read by nothing. `pnpm dedupe` was the one command that said anything, via a lockfile walk of its own after the install. An install that resolves now ends by applying `peerDependencyRules` to the issues its resolution left behind and either warning once — the same line the TypeScript CLI's reporter prints — or failing with `ERR_PNPM_PEER_DEP_ISSUES` under `strictPeerDependencies`, after the artifacts are written, the way `ERR_PNPM_IGNORED_BUILDS` already does. Living at the shared install tail means `add`, `remove`, `update`, `dedupe`, and `--lockfile-only` all get it, matching where pnpm places the call in `_installInContext`. Dedupe's own walk goes away as redundant. An install that skips resolution — frozen, or an up-to-date lockfile — still reports nothing, in both stacks. That asymmetry with `dedupe` is the subject of pnpm/pnpm#14098 and is deliberate: peer issues are a byproduct of resolution, so whatever ran one reports them, and `pnpm peers check` is what answers for a tree nobody re-resolved. Recomputing them on the frozen path would put a second, independent implementation on the hot path of every CI install and trade an install-vs-dedupe disagreement for an install-vs-install one. A test in each stack pins the decision. The verdict is read off the resolved lockfile rather than off the resolver's own issue map, because pacquet's `ParentChain` is name-only and would render every "Wanted:" entry with an empty version. That makes the lockfile walk shared code, so it moves out of the `peers` command into a new `pnpm-deps-inspection-peers` crate alongside the rules filter and the issue renderer — pnpm's `peers-checker` and `peers-issues-renderer` packages. Closes pnpm/pnpm#14098.
999 B
pacquet
| pacquet |
|---|
| minor |
An install that resolves the dependency graph now reports the unmet peer dependencies it leaves behind, matching the TypeScript CLI. By default it warns once — Issues with peer dependencies found. Run "pnpm peers check" to list them. — and with strictPeerDependencies it fails with ERR_PNPM_PEER_DEP_ISSUES after the artifacts are written, listing every unmet peer. This covers pnpm install, add, remove, update and --lockfile-only; pnpm dedupe reported the same verdict already, and now shares the reporting with them. peerDependencyRules are applied before the verdict, so a rule that covers every issue leaves nothing to report, and a --filtered install reports only on the projects it installed. An install that skips resolution — a frozen install, or one whose pnpm-lock.yaml is already up to date — reports nothing, as in the TypeScript CLI; pnpm peers check inspects such a tree #14098.