Description

In resolvePeers(), propagation skips adding a transitive peer only when parentEntry.children[tpd]
exists, but children is keyed by dependency alias, not necessarily the peer/package name. With npm
aliases (alias != resolvedPackage.name), this can incorrectly propagate an unnecessary
transitivePeerDependencies entry into parents, impacting lockfile contents and downstream
resolution/hoisting decisions.

Code

installing/deps-resolver/src/resolvePeers.ts[R254-257]

+      for (const tpd of childEntry.transitivePeerDependencies) {
+        if (!parentEntry.transitivePeerDependencies.has(tpd) && !parentEntry.peerDependencies?.[tpd] && !parentEntry.children?.[tpd]) {
+          parentEntry.transitivePeerDependencies.add(tpd)
+          gained = true

Evidence

The propagation filter uses children[tpd], but children is keyed by alias, and the resolver
explicitly supports alias != resolved package name; therefore direct aliased children won’t be
detected by this guard. Extra TPDs are persisted and later interpreted as peer constraints / as a
signal to force deeper resolution, so incorrect additions have real behavioral impact.

installing/deps-resolver/src/resolvePeers.ts[185-193]
installing/deps-resolver/src/resolvePeers.ts[1245-1261]
installing/deps-resolver/src/resolvePeers.ts[224-260]
installing/deps-resolver/src/resolveDependencies.ts[1156-1166]
installing/linking/real-hoist/src/index.ts[173-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`resolvePeers()` propagates `transitivePeerDependencies` upward using this guard:
- `!parentEntry.children?.[tpd]`
However, `children` is keyed by **alias**, while `tpd` entries are **peer/package names**. When a dependency is installed via npm alias, the alias key differs from the resolved package name, so the guard can fail even if the parent already has a direct child that satisfies that peer.
This can cause extra `transitivePeerDependencies` to be written to the lockfile, and those entries are later treated as peer constraints during hoisting/resolution.
### Issue Context
- `children` map is built from `childrenNodeIds` where keys are aliases.
- The resolver explicitly models that alias may differ from `resolvedPackage.name`.
### Fix Focus Areas
- installing/deps-resolver/src/resolvePeers.ts[224-263]
- installing/deps-resolver/src/resolvePeers.ts[185-193]
- installing/deps-resolver/src/resolvePeers.ts[1245-1261]
### Implementation direction
1. Replace the `!parentEntry.children?.[tpd]` check with a check that the parent already provides `tpd` as either:
- a direct child alias matching `tpd`, **or**
- a direct child whose **resolved package name** matches `tpd`.
Example approach (keep it efficient):
- Precompute for each node a `providedNames: Set<string>` that includes:
 - all child aliases (keys of `children`)
 - all child resolved names (`depGraphWithResolvedChildren[childPath]?.name`)
- Then guard with `!providedNames.has(tpd)`.
2. Add/extend a unit/integration test covering propagation where the parent provides the peer via an npm alias (alias != real name) to ensure TPD is not redundantly propagated.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

compatible_existing_peer_contexts_survive_writable_lockfile_regeneration is documented as
“Ignored” due to a known lockfile-reuse bug, but it is still annotated with #[test] and has no
#[ignore], so it will run in CI and can fail the suite. This contradicts the comment and
undermines test-suite reliability.

Code

pacquet/crates/cli/tests/install.rs[R865-874]

+/// Ignored: the TPD propagation fix (pnpm/pnpm#12286) correctly adds
+/// `@pnpm.e2e/peer-c` to `abc-grand-parent-with-c`'s transitive peer
+/// deps. The lockfile now records this TPD, and on the second install
+/// pacquet's lockfile-reuse path merges the nested `peer-c@1.x`
+/// context into the root `peer-c@2.0.0` context instead of preserving
+/// both. This is a pacquet lockfile-reuse bug exposed by correct TPD,
+/// not a bug in the propagation itself. The fix belongs in the reuse
+/// path, not in the propagation.
#[test]
fn compatible_existing_peer_contexts_survive_writable_lockfile_regeneration() {

Evidence

The test’s doc comment explicitly says it is ignored, but the code only has #[test] (no
#[ignore]). The same file contains another test that is correctly ignored with `#[ignore =
"..."]`, showing the expected mechanism.

pacquet/crates/cli/tests/install.rs[865-874]
pacquet/crates/cli/tests/install.rs[140-147]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A pacquet CLI integration test is described as ignored (due to a known lockfile-reuse bug), but it is still enabled as a normal `#[test]` with no `#[ignore]` attribute. This will keep executing in CI and may fail, blocking merges.
### Issue Context
The file already demonstrates the intended pattern for ignoring flaky/known-bad tests using `#[ignore = "..."]` above `#[test]`.
### Fix Focus Areas
- pacquet/crates/cli/tests/install.rs[865-874]
- pacquet/crates/cli/tests/install.rs[140-147]
### Expected fix
Add `#[ignore = "…reason…"]` above `#[test]` for `compatible_existing_peer_contexts_survive_writable_lockfile_regeneration`, or remove/update the “Ignored” comment if the test is intended to run and is now passing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet, propagate_transitive_peer_dependencies()/resolvePeers() can propagate a child’s
transitive peer dependency alias into a parent even when that alias already exists as a direct child
dependency on the parent, misclassifying a real dependency edge as a transitive peer. Because
lockfile reuse and hoisting treat transitivePeerDependencies specially, this collision can change
peer/hoist constraints and even cause snapshot-based reconstruction to drop the direct dependency
alias.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R389-399]

+                    let diff: Vec<String> = child
+                        .transitive_peer_dependencies
+                        .iter()
+                        .filter(|tpd| {
+                            !parent.transitive_peer_dependencies.contains(*tpd)
+                                && !parent.peer_dependencies.contains_key(*tpd)
+                        })
+                        .cloned()
+                        .collect();
+                    if diff.is_empty() { None } else { Some((parent_path.clone(), diff)) }
+                })

Evidence

The cited propagation logic only guards against adding aliases already in the parent’s transitive
peer set and/or declared peer_dependencies, but it does not check whether the alias is already
present as a direct child dependency in the parent’s children map. In contrast, earlier
peer-resolution logic explicitly enforces an invariant that excludes aliases that are direct
children when handling “unknown resolved peers,” showing the intended constraint exists elsewhere
but is missing from the new propagation loop. Downstream, snapshot_child_refs() explicitly filters
out any alias listed in peer_dependencies or transitive_peer_dependencies when reconstructing child
edges during lockfile reuse, so if propagation erroneously adds a real direct dependency alias into
transitive_peer_dependencies, reuse can omit that dependency; similarly, the hoister treats
transitivePeerDependencies entries as peer names, so misclassification affects hoisting/peer-name
behavior and lockfile semantics.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[360-410]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1503-1539]
installing/deps-resolver/src/resolvePeers.ts[185-225]
installing/deps-resolver/src/resolvePeers.ts[1107-1113]
installing/linking/real-hoist/src/index.ts[179-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The child-to-parent propagation of `transitivePeerDependencies` (Rust: `propagate_transitive_peer_dependencies()` in peer resolution; TS: `resolvePeers()` propagation pass) does not skip aliases that are already present as *direct child dependencies* of the parent (`parent.children` / `parentEntry.children`). This can incorrectly classify a real direct dependency alias as a transitive peer, which then affects hoisting/peer-name constraints and can cause lockfile reuse to drop the dependency because the reuse path filters out anything listed in `transitive_peer_dependencies`.
## Issue Context
- The propagation filter/condition currently checks for existing transitive-peer entries and declared `peer_dependencies`, but it does not check whether the alias already exists in the parent’s direct `children` map.
- Elsewhere in peer resolution (e.g., resolving peers of children / “unknown resolved peers”), the logic already avoids bubbling peers that are direct children (`if (!children[alias]) ...`), indicating the invariant that direct children should not be reclassified as transitive peers.
- In the lockfile reuse path, `snapshot_child_refs()` reconstructs dependencies from snapshot maps while excluding any alias in `peer_dependencies` or `transitive_peer_dependencies`, so an incorrect propagation collision can silently remove a real dependency edge during reuse.
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[360-410]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1503-1539]
- installing/deps-resolver/src/resolvePeers.ts[185-225]
- installing/deps-resolver/src/resolvePeers.ts[1107-1113]
## Suggested change
- Rust: In the `filter(|tpd| ...)` (or equivalent) predicate that decides whether to propagate a `tpd` into the parent, also ensure the parent does **not** already have that alias in `parent.children` (e.g., add a `!parent.children.contains_key(*tpd)` guard).
- TypeScript: In the propagation condition, also skip propagation when the parent already has that alias as a direct child dependency (use an own-property check like `Object.prototype.hasOwnProperty.call(parentEntry.children, tpd)` rather than truthiness).
- Keep existing guards (do not add if it is already in the parent’s `transitivePeerDependencies` and/or is a declared `peerDependency`), but add the missing `children`-presence check to preserve the invariant and prevent lockfile reuse/hoisting misbehavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet's transitive peer propagation, parents_of stores parents in a Vec, so the same parent
can be recorded multiple times for the same child_path when that child depPath is reachable under
multiple aliases (e.g. dependency alias plus resolved-peer alias). This causes repeated propagation
work for the same parent/child relationship and can add avoidable CPU/allocations in a resolver hot
path.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R454-460]

+    let mut parents_of: HashMap<DepPath, Vec<DepPath>> = HashMap::new();
+    let mut provided_names: HashMap<DepPath, HashSet<String>> = HashMap::new();
+    for (parent_path, entry) in graph.iter() {
+        let mut names = HashSet::new();
+        for (alias, child_path) in &entry.children {
+            parents_of.entry(child_path.clone()).or_default().push(parent_path.clone());
+            names.insert(alias.clone());

Evidence

The propagation pass currently records parent depPaths in a Vec without deduplication. The graph
node children map can contain multiple aliases pointing to the same depPath because it contains
both dependency edges and resolved peer edges, making duplicates feasible and leading to redundant
parent processing.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[453-468]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1144-1166]
pacquet/crates/resolving-deps-resolver/src/dependencies_graph.rs[32-36]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`propagate_transitive_peer_dependencies()` builds `parents_of` as `HashMap<DepPath, Vec<DepPath>>` and pushes `parent_path` once per `(alias, child_path)` edge. If multiple aliases point to the same `child_path` (which can happen because graph `children` includes both normal child edges and resolved-peer edges), the same `parent_path` is duplicated and the parent is processed multiple times for the same child.
### Issue Context
This is a propagation post-pass in the resolver; keeping its complexity proportional to unique edges helps avoid regressions on large graphs and alias-heavy dependency trees.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[453-468]
### Suggested fix
- Change `parents_of` to dedupe parents per child, e.g. `HashMap<DepPath, HashSet<DepPath>>` (or keep `Vec` but guard against duplicates).
- Update the iteration accordingly (iterate the `HashSet` of parents).
- Keep the rest of the algorithm unchanged to preserve behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In resolvePeers(), providedNames only records a child’s real package name when that child has an
entry in depGraphWithResolvedChildren, but linked deps (link:) don’t have graph nodes, so their
real names are omitted. If a linked dependency is installed under an alias different from its real
name, the propagation loop can incorrectly add a transitivePeerDependencies entry for a peer that
is already directly provided by that linked child, producing incorrect/stable-lockfile-breaking
snapshots.

Code

installing/deps-resolver/src/resolvePeers.ts[R228-236]

+    for (const [alias, childPath] of Object.entries<DepPath>(entry.children)) {
+      if (!parentsOf[childPath]) {
+        parentsOf[childPath] = new Set()
+      }
+      parentsOf[childPath].add(parentPath as DepPath)
+      names.add(alias)
+      const childEntry = depGraphWithResolvedChildren[childPath]
+      if (childEntry?.name) names.add(childEntry.name)
+    }

Evidence

Linked deps are inserted into dependenciesTree with depth: -1, and resolvePeersOfNode()
returns early for depth === -1, so no dep-graph entry is created and no pathsByNodeId mapping is
set. resolveChildren() therefore emits link: strings as child depPaths, but providedNames only
adds the child’s real name when it can find a dep-graph entry for that child depPath, which linked
deps lack; the propagation filter then can’t recognize the real-name peer as already provided by the
parent’s direct linked child.

installing/deps-resolver/src/resolveDependencies.ts[932-946]
installing/deps-resolver/src/resolvePeers.ts[483-485]
installing/deps-resolver/src/resolvePeers.ts[185-191]
installing/deps-resolver/src/resolvePeers.ts[224-236]
installing/deps-resolver/src/updateLockfile.ts[175-194]
installing/deps-resolver/src/resolvePeers.ts[505-516]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new worklist propagation builds `providedNames` from `depGraphWithResolvedChildren[childPath]?.name`. For linked children, `childPath` is a `link:` depPath and there is no dep-graph entry, so the child’s real package name is never recorded. This can cause the propagation loop to treat a peer as “not provided by parent” and incorrectly propagate it.
### Issue Context
- Linked deps are represented in the dependencies tree with `depth: -1`, and `resolvePeersOfNode()` early-returns for them, so they never get a dep-graph node/depPath mapping.
- `resolveChildren()` then falls back to using the raw `link:` nodeId as the child depPath.
### Fix Focus Areas
- installing/deps-resolver/src/resolvePeers.ts[224-236]
### Suggested change
While building `providedNames`, when `childEntry` is missing and `childPath` starts with `link:`, look up the corresponding node in `opts.dependenciesTree` (the key is the same `link:...` string) and add `node.resolvedPackage.name` to `names` as well. This mirrors the alias-vs-real-name handling you already do for graph-backed children.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet's propagate_transitive_peer_dependencies(), the VecDeque worklist has no in-queue
deduplication, so the same parent DepPath can be re-enqueued and reprocessed many times as different
children contribute new transitive peers, increasing CPU and allocations on large graphs.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R350-385]

+    let mut worklist: VecDeque<DepPath> = graph
+        .iter()
+        .filter(|(_, entry)| !entry.transitive_peer_dependencies.is_empty())
+        .map(|(path, _)| path.clone())
+        .collect();
+
+    while let Some(child_path) = worklist.pop_front() {
+        let child_tpd: Vec<String> = graph
+            .get(&child_path)
+            .map(|c| c.transitive_peer_dependencies.iter().cloned().collect())
+            .unwrap_or_default();
+        if child_tpd.is_empty() {
+            continue;
+        }
+        let Some(parents) = parents_of.get(&child_path).cloned() else { continue };
+
+        for parent_path in parents {
+            let mut new_tpd = Vec::new();
+            {
+                let Some(parent) = graph.get(&parent_path) else { continue };
+                for tpd in &child_tpd {
+                    if !parent.transitive_peer_dependencies.contains(tpd)
+                        && !parent.peer_dependencies.contains_key(tpd)
+                    {
+                        new_tpd.push(tpd.clone());
+                    }
+                }
+            }
+            if !new_tpd.is_empty() {
+                let parent = graph.get_mut(&parent_path).unwrap();
+                for tpd in new_tpd {
+                    parent.transitive_peer_dependencies.insert(tpd);
+                }
+                worklist.push_back(parent_path);
+            }
+        }

Evidence

The Rust implementation re-enqueues nodes without any deduplication, while the TS implementation
uses a Set worklist, demonstrating the intended deduped behavior and highlighting the Rust port’s
redundant-queue risk.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[339-387]
installing/deps-resolver/src/resolvePeers.ts[195-224]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`propagate_transitive_peer_dependencies()` uses a `VecDeque` worklist and blindly `push_back`s `parent_path` whenever a parent gains new TPD entries. This can enqueue the same `DepPath` many times, causing redundant processing and avoidable superlinear behavior in graphs with shared parents / many incremental TPD additions.
### Issue Context
The TypeScript implementation uses a `Set` worklist (deduped). The Rust port should match that behavior to keep propagation cost proportional to actual new information.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[339-387]
### Suggested approach
- Keep `VecDeque<DepPath>` for FIFO order, but add a `HashSet<DepPath>` (e.g. `in_queue`) to prevent duplicates.
- When enqueuing: `if in_queue.insert(parent_path.clone()) { worklist.push_back(parent_path.clone()) }`
- When popping: `in_queue.remove(&child_path)`
- Optionally also dedupe `parents_of` (store `HashSet<DepPath>` instead of `Vec`) to avoid repeated parent processing when the same child edge appears multiple times.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

resolvePeersOfNode() now performs an extra linear Array.includes() scan on parentDepPathsChain to
compute resolvedThroughCycle even though the same membership check was already done earlier when
extending parentDepPathsChain for child resolution. This adds avoidable O(depth) work per visited
node in a recursive resolver hot path.

Code

installing/deps-resolver/src/resolvePeers.ts[R601-606]

+  const resolvedThroughCycle = ctx.parentDepPathsChain.includes(resolvedPackage.pkgIdWithPatchHash)
+  if (resolvedThroughCycle) {
+    // Leave both caches untouched so later occurrences re-resolve (or hit the
+    // authoritative entry of the same package) instead of reusing this partial one.
+  } else if (isPure) {
    ctx.purePkgs.add(resolvedPackage.pkgIdWithPatchHash)

Evidence

The code already does an includes() check to decide whether to extend the chain for child
resolution, and the new resolvedThroughCycle introduces a second includes() scan for the same
value.

installing/deps-resolver/src/resolvePeers.ts[555-563]
installing/deps-resolver/src/resolvePeers.ts[593-606]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`resolvePeersOfNode()` calls `ctx.parentDepPathsChain.includes(resolvedPackage.pkgIdWithPatchHash)` twice: once to decide whether to extend `parentDepPathsChain` for `resolvePeersOfChildren`, and again later to compute `resolvedThroughCycle`.

Because `parentDepPathsChain` is an array and `includes()` is linear, this adds avoidable per-node work in a recursive resolver hot path.

### Issue Context
The first `includes()` result is already sufficient to decide whether the current node is being resolved through a cycle and can be reused for the later cache decision.

### Fix Focus Areas
- installing/deps-resolver/src/resolvePeers.ts[555-563]
- installing/deps-resolver/src/resolvePeers.ts[593-606]

### Suggested fix
Compute a single `const resolvedThroughCycle = ctx.parentDepPathsChain.includes(resolvedPackage.pkgIdWithPatchHash)` once (before the `resolvePeersOfChildren` call), reuse it both:
- when building the `parentDepPathsChain` passed to children, and
- when deciding whether to populate `purePkgs` / `peersCache`.

Optionally, if this becomes more performance-sensitive, consider threading a boolean or using a Set-based structure for cycle membership checks.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In pacquet, propagate_transitive_peer_dependencies clones the parent list per dequeued node and
builds an intermediate diffs Vec<(DepPath, Vec<String>)> before applying updates, causing avoidable
allocations in a resolver hot path. This is unlikely to break correctness but can be optimized to
reduce CPU/allocations on large dependency graphs.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R375-401]

+        let Some(parents) = parents_of.get(&child_path).cloned() else { continue };
+
+        let diffs: Vec<(DepPath, Vec<String>)> = {
+            let child = match graph.get(&child_path) {
+                Some(c) => c,
+                None => continue,
+            };
+            if child.transitive_peer_dependencies.is_empty() {
+                continue;
+            }
+            parents
+                .iter()
+                .filter_map(|parent_path| {
+                    let parent = graph.get(parent_path)?;
+                    let diff: Vec<String> = child
+                        .transitive_peer_dependencies
+                        .iter()
+                        .filter(|tpd| {
+                            !parent.transitive_peer_dependencies.contains(*tpd)
+                                && !parent.peer_dependencies.contains_key(*tpd)
+                        })
+                        .cloned()
+                        .collect();
+                    if diff.is_empty() { None } else { Some((parent_path.clone(), diff)) }
+                })
+                .collect()
+        };

Evidence

The new propagation loop clones the parent list (.cloned()) and constructs an intermediate diffs
vector for each work item, then iterates that vector again to apply mutations, increasing
allocations in a tight loop.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[360-411]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`propagate_transitive_peer_dependencies()` performs avoidable cloning/allocation in its inner loop:
- clones the `parents` Vec for every `child_path`
- collects an intermediate `diffs: Vec<(DepPath, Vec<String>)>` (and each `diff: Vec<String>`) before mutating the graph
This adds overhead in `resolve_peers()` / `resolve_peers_workspace()` where the resolver runs frequently.
### Issue Context
The function is called right after `build_final_graph()` and before returning the resolved graph, so any extra allocations show up directly in install/resolve time.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[360-411]
### Suggested approach
- Avoid cloning `parents` by iterating over `parents_of.get(&child_path)` by reference.
- Avoid allocating `diffs` by performing the parent updates in a second pass that only clones the child's TPD set once (or iterates it directly), using a `gained` flag per parent.
- If borrow rules block in-place mutation while iterating parents, collect only the parent depPaths that need updates (no per-parent Vec<String>) and then apply updates.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🐞 Bugs (8) 📘 Rule violations (0) 📎 Requirement gaps (0)

Walkthrough

This PR adds transitive peer dependency propagation across both TypeScript and Rust dependency resolvers to prevent lockfile churn. When resolving peer dependencies, the algorithm now floods transitive peer names upward through parent nodes after resolution, using a worklist-based approach that skips peers already satisfied by direct declarations or provided aliases.

Changes

Transitive Peer Dependencies Propagation

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• pnpm/pnpm#5108: Unexpected lockfile churn when upgrading packages manually in monorepo environments due to transitive peer dependency shifts.
• pnpm/pnpm#5552: Selective pnpm update foo unintentionally updates packages unrelated to the specified package.
• pnpm/pnpm#5794: Lockfile changes during pnpm install not reflected in pnpm install --frozen-lockfile, indicating lockfile state divergence.
• pnpm/pnpm#9992: Selective package updates inadvertently fetch unrelated packages into the dependency tree due to transitive peer dependency instability.

Possibly related PRs

• pnpm/pnpm#11915: Modifies pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs with lazy-walker changes to peer-resolution logic that complements the upward propagation added in this PR.
• pnpm/pnpm#12273: Also modifies pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs affecting parent-context peer-resolution logic alongside the propagation propagation step introduced here.

Suggested reviewers

• zkochan

Poem

🐰 A worklist hops up the dependency tree,
Each transitive peer finds where it should be,
No churn in the lock when unrelated things shift,
The graph stays stable—a propagation gift! 📦✨

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

Summary

Fixes lockfile churn where transitivePeerDependencies (e.g., supports-color via debug) shift between packages when unrelated dependencies are upgraded.

Root cause: The purePkgs optimization in resolvePeersOfNode marks packages as "pure" deep inside cycles (where cycle-breaking produces empty children). When resolved again at shallower depths through a different parent path, the purePkgs early return yields empty missing peers, causing transitivePeerDependencies inconsistency. Resolution order changes with unrelated upgrades, so the lockfile churns.

Fix: Post-processing worklist-based propagation loop that runs after all peer resolutions complete. Seeds a worklist with nodes that have non-empty transitivePeerDependencies, then propagates tpd from each node to its parents. Parents that gain new tpd entries are added to the worklist. Filters out peers the parent declares in its own peerDependencies. Complexity is O(total_propagations × avg_parents) — proportional to actual work, not graph size.

Both the TypeScript pnpm CLI and the Rust (pacquet) port are updated in parity.

Fixes #5108
Fixes #5552
Fixes #5794
Fixes #9992
Fixes #11834

Test plan

• 109 resolver unit tests pass (TS)
• 95 resolver tests pass (Rust)
• 3 integration tests for lockfile stability + idempotency (TS)
• Direct graph-construction unit tests for propagation (Rust) — 2 of 3 fail without the propagation call
• Verified on real-world repro: fresh install + upgrade produces zero tpd churn, second install is idempotent
• Benchmark shows no measurable performance regression vs main (22.6s ± 0.9s vs 22.8s ± 0.8s, npm registry, frozen lockfile)

Written by an agent (opencode, glm-5.1).

• Propagate transitivePeerDependencies upward through the resolved dep graph to avoid lockfile
  churn.
• Add regression coverage for peer cycles and “unrelated upgrade” determinism/idempotency.
• Port the fix to pacquet (Rust) with parity tests and small tooling updates.

The following are alternative approaches to this PR:

Recommendation: The PR’s approach (a worklist-based propagation pass after child edges are finalized) is the most robust: it makes transitivePeerDependencies a fixed-point property of the final depGraph, eliminating order sensitivity introduced by the purePkgs fast-path. The worklist algorithm keeps cost proportional to actual propagation, and parity across TS/Rust reduces long-term drift.

resolvePeers.ts Propagate transitivePeerDependencies to parents via worklist post-pass +42/-0

Propagate transitivePeerDependencies to parents via worklist post-pass

• Builds a child→parents index after 'resolveChildren', seeds a worklist with nodes that already have TPD, and propagates each child’s TPD to its parents until convergence. Filters out entries that the parent declares in its own 'peerDependencies' to avoid misclassification.

installing/deps-resolver/src/resolvePeers.ts

---

resolve_peers.rs Port worklist-based TPD propagation to pacquet resolver +53/-1

Port worklist-based TPD propagation to pacquet resolver

• Introduces 'propagate_transitive_peer_dependencies' using a parent index and 'VecDeque' worklist, filtering out parent-declared peers. Invokes the propagation after 'patch_pending_peer_edges' in both workspace and non-workspace resolve flows to ensure children maps are populated before propagation.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs

---

cyclicPeerDeterminism.ts Add integration test for TPD propagation across dependency cycles +100/-0

Add integration test for TPD propagation across dependency cycles

• Creates a mocked registry topology with an 'a↔b' cycle and a second path to 'a', where an optional peer should surface as a transitive peer dependency. Verifies snapshots contain the expected TPD and that a second run produces identical snapshot keys (idempotency).

installing/deps-installer/test/install/cyclicPeerDeterminism.ts

---

peerDependencies.ts Add lockfile stability tests for transitivePeerDependencies +66/-0

Add lockfile stability tests for transitivePeerDependencies

• Adds integration coverage ensuring TPD values are stable across repeated installs and do not churn when adding an unrelated dependency. Asserts carrier snapshots consistently record the same transitive peer dependency.

installing/deps-installer/test/install/peerDependencies.ts

---

resolvePeers.ts Add unit test for TPD propagation after purePkgs early return in cycles +136/-0

Add unit test for TPD propagation after purePkgs early return in cycles

• Constructs a dependency tree where a cycle causes a node to be marked pure and later revisited through a different parent path. Asserts that the post-pass propagation ensures upstream nodes still receive the expected transitive peer dependency.

installing/deps-resolver/test/resolvePeers.ts

---

tests.rs Add Rust parity and unit tests for TPD propagation +402/-0

Add Rust parity and unit tests for TPD propagation

• Adds topology tests mirroring the TypeScript cycle regression and a multi-parent carrier scenario to ensure TPD reaches all parents deterministically. Adds direct graph-construction unit tests validating propagation, filtering of parent-declared peers, and transitive multi-level propagation.

pacquet/crates/resolving-deps-resolver/src/tests.rs

---

package.json Add fixture package declaring an optional peer +12/-0

Add fixture package declaring an optional peer

• Defines '@pnpm.e2e/has-optional-peer' with an optional 'peerDependencies' entry used to induce transitive peer dependency recording in tests.

pnpr/.fixtures/packages/@pnpm.e2e/has-optional-peer/1.0.0/package.json

---

package.json Add carrier A fixture for TPD stability scenarios +7/-0

Add carrier A fixture for TPD stability scenarios

• Adds '@pnpm.e2e/transitive-peer-carrier-a' which depends on the chain that introduces an optional peer, serving as a lockfile snapshot carrier in integration tests.

pnpr/.fixtures/packages/@pnpm.e2e/transitive-peer-carrier-a/1.0.0/package.json

---

package.json Add carrier B fixture for TPD stability scenarios +7/-0

Add carrier B fixture for TPD stability scenarios

• Adds '@pnpm.e2e/transitive-peer-carrier-b' mirroring carrier A to validate stability across multiple similar parents.

pnpr/.fixtures/packages/@pnpm.e2e/transitive-peer-carrier-b/1.0.0/package.json

---

package.json Add parent fixture depending on both carriers +9/-0

Add parent fixture depending on both carriers

• Adds '@pnpm.e2e/transitive-peer-parent' depending on both carrier packages (plus an unrelated dep) to exercise snapshot determinism under dependency changes.

pnpr/.fixtures/packages/@pnpm.e2e/transitive-peer-parent/1.0.0/package.json

---

package.json Add fixture package that pulls in optional-peer package +7/-0

Add fixture package that pulls in optional-peer package

• Defines '@pnpm.e2e/uses-optional-peer' which depends on '@pnpm.e2e/has-optional-peer', forming the chain that produces a transitive peer dependency in the lockfile.

pnpr/.fixtures/packages/@pnpm.e2e/uses-optional-peer/1.0.0/package.json

---

tpd-propagation-fix.md Add changeset entry for lockfile churn fix +6/-0

Add changeset entry for lockfile churn fix

• Introduces a patch changeset for '@pnpm/installing.deps-resolver' and 'pnpm' documenting the transitivePeerDependencies churn fix.

.changeset/tpd-propagation-fix.md

---

cspell.json Allow 'worklist' spelling in repo dictionary +1/-0

Allow 'worklist' spelling in repo dictionary

• Adds the term "worklist" to the cspell dictionary to match the new algorithm terminology.

cspell.json

---

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Full review finished.