Walkthrough

Threads explicit parent-node and parent-package context through resolve_peers, centralizes realized-vs-pending graph-child insertion, strengthens cache/parent matching (including optional peers and version-only compatibility), refactors parent-ref overwrite/version logic, adds tests for alias/diamond scenarios, and updates a CI workflow action.

Changes

Peer Resolution Core Refactor and Tests

Sequence Diagram(s)

sequenceDiagram
  participant CLI_Test
  participant Walker
  participant resolve_node
  participant add_graph_child_or_pending
  participant Lockfile

  CLI_Test->>Walker: start walk (seed parent refs)
  Walker->>resolve_node: resolve_node(parent_node_ids, parent_pkg_ids_chain)
  resolve_node->>add_graph_child_or_pending: insert child/peer or defer to pending_peer_edges
  add_graph_child_or_pending->>Lockfile: record realized edges / pending edges
  resolve_node->>Walker: return resolved node + ParentRefs
  Walker->>Lockfile: finalize pending edges and write pnpm-lock.yaml

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related issues

• pacquet: lockfile-parity gaps vs pnpm CLI (npm: aliases, minimumReleaseAge, peer suffixes) #12266: The changes rework resolve_peers internals and alias/depPath behavior that target the lockfile-parity and peer-sharing issues described in this issue.

Possibly related PRs

• pnpm/pnpm#12081: Implements related diamond-conflict checks and tests for consistent peer resolution.
• pnpm/pnpm#11906: Related purePkgs fast-path and cache/compatibility changes in resolve_peers.rs.
• pnpm/pnpm#12267: Overlapping work on pending-edge patching and depPath finalization in resolve_peers.rs.

Poem

"I hop through nodes with parent chains in tow,
I nudge pending edges where depPaths don't show.
With helpers stitched and tests that pry,
Diamond peers settle — no mixed supply.
A rabbit cheers: one graph, shared and low! 🐇"

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

• X
• Mastodon
• Reddit
• LinkedIn

Description

In Walker::resolve_node, peer-provider ParentRefs are only added when the child’s install alias is
in all_peer_dep_names, so an npm-alias child whose real package name is peer-relevant can be omitted
entirely. This can incorrectly mark peers as missing and produce wrong depPaths/peer suffixes for
descendants.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R733-747]

for (alias, child_node_id) in &children_map {
+            if !self.tree.all_peer_dep_names.contains(alias) {
+                continue;
+            }
   let Some(child_tree) = self.tree.dependencies_tree.get(child_node_id) else { continue };
   let Some(child_pkg) = self.tree.packages.get(&child_tree.resolved_package_id) else {
       continue;
   };
-            let (child_real_name, child_version) = pkg_name_version(&child_pkg.result);
-            // Only peer-relevant aliases need to land in `parentRefs`.
-            // Pnpm filters with `allPeerDepNames` to keep the propagated
-            // map small.
-            let alias_relevant = self.tree.all_peer_dep_names.contains(alias);
-            let real_relevant = self.tree.all_peer_dep_names.contains(&child_real_name);
-            if !alias_relevant && !real_relevant {
-                continue;
-            }
-            let parent_ref = ParentRef {
-                version: child_version,
-                node_id: Some(child_node_id.clone()),
-                alias: (alias != &child_real_name).then(|| alias.clone()),
-                depth: child_depth,
-                occurrence: 0,
-            };
-            if alias_relevant {
-                bump_occurrence_on_shadow(&mut child_parent_refs, alias, &parent_ref);
-            }
-            if real_relevant && alias != &child_real_name {
-                bump_occurrence_on_shadow(&mut child_parent_refs, &child_real_name, &parent_ref);
+            insert_parent_ref(
+                &mut new_parent_refs,
+                alias,
+                child_node_id.clone(),
+                child_pkg,
+                child_tree.depth,
+            );

Evidence

The code documents that ParentRefs should be keyed by both alias and real name, but the new
resolve_node filter checks only the install alias, so aliased children can be dropped before
insert_parent_ref has a chance to add the real-name key.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[352-357]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[729-748]

Agent prompt

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

## Issue description
`Walker::resolve_node` builds `new_parent_refs` from `children_map`, but it currently skips a child unless the **install alias** is in `all_peer_dep_names`. For npm-alias dependencies where the **real package name** is peer-relevant but the alias is not, the provider never makes it into `ParentRefs` (neither under alias nor real name), breaking peer resolution.
### Issue Context
- `ParentRefs` is meant to be dual-keyed by alias and real name (when they differ), so peers can be satisfied by either key.
- The current loop filters by `alias` before it even computes/considers the child’s real name.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[733-767]
### Implementation notes
- In the `for (alias, child_node_id) in &children_map` loop:
- Load `child_pkg` (already done).
- Compute `child_real_name` via `pkg_name_version(&child_pkg.result).0`.
- Change the early-continue condition to:
- `continue` only if **neither** `all_peer_dep_names.contains(alias)` **nor** `all_peer_dep_names.contains(&child_real_name)`.
- Then call `insert_parent_ref(...)` as today (it already writes both alias + real-name entries).
- Add/adjust a focused unit test covering: alias name NOT in `all_peer_dep_names` while real name IS, and a descendant peer on the real name resolves successfully.

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

Description

insert_parent_ref now stores ParentRef.depth from DependenciesTreeNode.depth, but
DependenciesTreeNode.depth is explicitly minimized across all visits (it is not the current walk’s
occurrence depth). parent_packages_match uses this depth (via ParentPkgInfo) as part of its
shadowing/cache-compatibility guard, so distinct occurrences can be treated as compatible and reuse
cached peer resolutions under the wrong context, producing incorrect depPaths/graph output.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R615-619]

 };
 let parent_node_id = remap_link_node_id(&self.opts, &direct.alias, &pkg.result)
     .unwrap_or_else(|| direct.node_id.clone());
-            insert_parent_ref(&mut refs, &direct.alias, parent_node_id, pkg, self.tree);
+            insert_parent_ref(&mut refs, &direct.alias, parent_node_id, pkg, tree_node.depth);
}

Evidence

The code documents ParentRef.depth as the depth where the parent was added, and threads it into
ParentPkgInfo specifically so parent_packages_match can apply a depth-based fallback when peers
are shadowed. This PR now supplies that depth from DependenciesTreeNode.depth, but the dependency
tree intentionally stores the *minimum* depth observed for a NodeId across visits, so the stored
depth can differ from the current occurrence depth and undermine the cache/shadowing guard.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[324-349]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[607-620]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[731-767]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1632-1656]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1682-1726]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1756-1791]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1173-1196]

Agent prompt

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

## Issue description
`ParentRef.depth` is documented as “depth at which this parent was added” and is used downstream in `parent_packages_match` to decide whether a cached peer-resolution is compatible when shadowing (`occurrence > 0`) exists.
This PR now populates `ParentRef.depth` using `DependenciesTreeNode.depth` (`tree_node.depth` / `child_tree.depth`). But `DependenciesTreeNode.depth` is maintained as the *minimum depth across all occurrences* of that `NodeId`, which means it can be *shallower* than the actual occurrence depth for the current walk.
That breaks the intent of the depth-based guard in `parent_packages_match` and can allow (or deny) cache hits incorrectly, leading to incorrect peer-context reuse and wrong depPaths/graph output.
## Issue Context
`DependenciesTreeNode.depth` is intentionally “Math.min” across visits, so it’s not suitable as a per-occurrence depth signal.
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[599-820]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1632-1792]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1173-1196]
### Concrete fix direction
- Reintroduce a recursion-local `current_depth` (like the previous `depth` parameter) or compute it from the current call chain length, and use that value when constructing `ParentRef.depth`.
- Importer parents should use depth `0` (or the same semantics as before).
- Child-derived parents should use `parent_depth + 1`.
- Avoid using `DependenciesTreeNode.depth` for `ParentRef.depth` (it’s a global minimum).
- Keep `DependenciesTreeNode.depth` as-is for install ordering/graph node depth; just decouple it from peer-context depth tracking.
- Add/adjust a resolver unit test that creates the same parent package reachable at two depths and asserts that cache matching/shadowing behaves differently across the two occurrences (i.e., depth is not “flattened” by the global min depth).

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

Description

External peer bubbling is filtered using children_map.contains_key(peer_alias), but peer_alias
is keyed by the peer dependency name (real package name). For npm-aliased children where install
alias differs from real name, this fails to absorb the peer at the child node and can reintroduce
spurious peer-suffix propagation.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R848-851]

+                if children_map.contains_key(&peer_alias) {
       continue;
   }
   external_from_children.insert(peer_alias, peer_node_id);

Evidence

PR Compliance ID 1 requires name-keyed absorption of resolved peers when the node has a child with
the same package alias/name. The new code filters bubbling by checking
children_map.contains_key(peer_alias), but peers are recorded under peer_name in
resolve_one_peer, so a child installed under an npm alias will not match and the peer can
incorrectly bubble upward.

Align pacquet peer “bubble gate” behavior with pnpm (name-keyed absorption of peers listed as regular deps)
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[838-852]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1029-1032]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1045-1086]

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 peer absorption/bubbling filter checks only whether `children_map` contains the peer key (`children_map.contains_key(peer_alias)`), but peer keys are inserted using the peer dependency name (`peer_name`). This breaks name-keyed absorption when a child is present under an npm alias (install alias != real package name), allowing that peer to bubble upward.
## Issue Context
Compliance requires name-keyed absorption: if a node has a child with the same package alias/name, a resolved peer of that name must be considered internal and not bubbled. `children_map` is keyed by install alias, while peer resolution keys are `peer_name` (real name).
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[838-852]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1029-1032]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1045-1086]

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

Description

parent_packages_match now treats a parent-context mismatch as a version-only comparison whenever
either side has a version, which can reject otherwise shareable cache hits and lead to unnecessary
node/depPath variants across parents. This risks diverging from pnpm’s node sharing behavior and
reintroducing multi-variant outcomes (e.g., mixed-scope jest-config / @types/node cases).

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R1773-1778]

+            // Version-only match covers `link:` parents whose nodeIds
+            // don't index into the dependencies tree.
+            if cached_info.version.is_some() || current_info.version.is_some() {
             if cached_info.version == current_info.version {
                 continue;
             }

Evidence

Rule 2/4 require pnpm-equivalent reuse/sharing across parents to avoid unnecessary variant
duplication. The changed condition `if cached_info.version.is_some() ||
current_info.version.is_some()` forces version comparison in more cases than just
link:/version-only parents, which can incorrectly fail parentPackagesMatch and prevent cache
hits needed for depPath reuse.

Implement pnpm-equivalent node sharing across parents (depPath reuse / find_hit parity)
Prevent @types/node divergence by ensuring shared variant selection matches pnpm under mixed ancestor scopes
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1773-1778]

Agent prompt

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

## Issue description
`parent_packages_match` performs a version-only comparison when either `cached_info.version` or `current_info.version` is set. This can cause false cache misses in mixed cases (one side has `pkg_id`, the other only `version`), reducing depPath reuse and parent sharing.
## Issue Context
Version-only matching is intended to cover `link:` parents where the `NodeId` does not index into the dependencies tree. Mixed `pkg_id`/`version` cases should not automatically fall into the version-only branch if it prevents pnpm-equivalent sharing.
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1773-1778]

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

Description

The new install_with_peer_alias_deps() helper appends workspace settings but does not pin
peersSuffixMaxLength, while the new tests assert exact peer-suffix strings in pnpm-lock.yaml.
Because pacquet layers global config.yaml before pnpm-workspace.yaml, a developer’s global
config can change suffix rendering (including hashing when max length is small) and make these
contains(...) assertions fail.

Code

pacquet/crates/cli/tests/install.rs[R929-952]

+fn install_with_peer_alias_deps(dependencies: serde_json::Value) -> String {
+    let CommandTempCwd { pacquet, root, workspace, npmrc_info, .. } =
+        CommandTempCwd::init().add_mocked_registry();
+    let AddMockedRegistry { mock_instance, .. } = npmrc_info;
+
+    let workspace_yaml_path = workspace.join("pnpm-workspace.yaml");
+    let mut workspace_yaml =
+        fs::read_to_string(&workspace_yaml_path).expect("read pnpm-workspace.yaml");
+    if !workspace_yaml.ends_with('\n') {
+        workspace_yaml.push('\n');
+    }
+    workspace_yaml.push_str("autoInstallPeers: false\n");
+    workspace_yaml.push_str("strictPeerDependencies: false\n");
+    fs::write(&workspace_yaml_path, workspace_yaml).expect("write pnpm-workspace.yaml");
+
+    fs::write(
+        workspace.join("package.json"),
+        serde_json::json!({ "dependencies": dependencies }).to_string(),
+    )
+    .expect("write package.json");
+
+    pacquet.with_arg("install").assert().success();
+    let lockfile =
+        fs::read_to_string(workspace.join("pnpm-lock.yaml")).expect("read pnpm-lock.yaml");

Evidence

install_with_peer_alias_deps() currently only appends autoInstallPeers and
strictPeerDependencies, while the tests assert exact peer-suffix strings from the lockfile.
pacquet applies global config.yaml before pnpm-workspace.yaml, and global config is allowed to
set peersSuffixMaxLength (it is not cleared as a workspace-only field). If peersSuffixMaxLength
is small, create_peer_dep_graph_hash hashes long suffixes, changing the lockfile text and breaking
contains(...) assertions.

pacquet/crates/cli/tests/install.rs[929-956]
pacquet/crates/config/src/lib.rs[1585-1702]
pacquet/crates/config/src/workspace_yaml.rs[576-610]
pacquet/crates/deps-path/src/create_peer_dep_graph_hash.rs[24-33]

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 integration-test helper `install_with_peer_alias_deps()` writes `pnpm-workspace.yaml` but does not set `peersSuffixMaxLength`. The new tests match literal peer-suffix strings in `pnpm-lock.yaml`; if a developer/CI environment has a global pnpm `config.yaml` that sets a small peers-suffix max length, the suffix may be hashed and the assertions will fail.
### Issue Context
- pacquet config layering loads global `config.yaml` and applies it before `pnpm-workspace.yaml`, so global config can influence lockfile rendering.
- `create_peer_dep_graph_hash` replaces the suffix body with a short hash when it exceeds `max_length`.
### Fix Focus Areas
- pacquet/crates/cli/tests/install.rs[929-942]

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

Description

The importer ParentRefs is seeded with every direct dependency and then cloned per visited node,
even though only peer-relevant names are used for parent-context snapshots. This creates avoidable
HashMap cloning/allocations that can hurt performance in large dependency graphs.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R1806-1837]

direct_alias: &str,
parent_node_id: NodeId,
pkg: &ResolvedPackage,
-    tree: &ResolvedTree,
+    depth: i32,
) {
let (real_name, version) = pkg_name_version(&pkg.result);
-    let alias_relevant = tree.all_peer_dep_names.contains(direct_alias);
-    let real_relevant = tree.all_peer_dep_names.contains(&real_name);
-    if !alias_relevant && !real_relevant {
-        return;
-    }
let parent_ref = ParentRef {
version,
node_id: Some(parent_node_id),
alias: (direct_alias != real_name).then(|| direct_alias.to_string()),
-        depth: 0,
+        depth,
occurrence: 0,
};
-    if alias_relevant {
-        refs.insert(direct_alias.to_string(), parent_ref.clone());
+    update_parent_refs(refs, direct_alias, &parent_ref);
+    if direct_alias != real_name {
+        update_parent_refs(refs, &real_name, &parent_ref);
+    }
+}
+
+fn update_parent_refs(refs: &mut ParentRefs, new_alias: &str, parent_ref: &ParentRef) {
+    if let Some(existing) = refs.get(new_alias) {
+        let existing_has_alias = existing.alias.as_deref().is_some_and(|alias| alias != new_alias);
+        if !existing_has_alias {
+            return;
+        }
+        let new_has_alias = parent_ref.alias.as_deref().is_some_and(|alias| alias != new_alias);
+        if new_has_alias && version_gte(&existing.version, &parent_ref.version) {
+            return;
+        }
}
-    if real_relevant && direct_alias != real_name {
-        refs.insert(real_name, parent_ref);
+    refs.insert(new_alias.to_string(), parent_ref.clone());
+}

Evidence

Importer parents are populated by iterating all direct deps and calling insert_parent_ref, while
resolve_node clones ParentRefs per node; meanwhile, parent_dep_paths_from_refs explicitly ignores
non-peer-relevant names, indicating extra ParentRefs entries are overhead rather than functional
inputs.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[607-620]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[729-733]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1624-1633]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1804-1837]

Agent prompt

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

## Issue description
`ParentRefs` is cloned (`parent_parent_refs.clone()`) as part of normal traversal. After this PR, `build_importer_parents_from` seeds `ParentRefs` for **all** direct dependencies via `insert_parent_ref`/`update_parent_refs` without any peer-relevance gating, even though downstream snapshots (`parent_dep_paths_from_refs`) explicitly filter to `all_peer_dep_names`. This can lead to unnecessary cloning/heap work proportional to `(visited nodes) × (direct deps)`.
### Issue Context
- `parent_dep_paths_from_refs` already filters to peer-relevant names, so non-peer-relevant direct deps don’t contribute to `parent_pkgs_of_node`/cache matching.
- Keeping `ParentRefs` minimal reduces cloning/merging work without changing resolution semantics for peers.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[607-621]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[729-733]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1624-1633]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1804-1837]
### Implementation notes
- In `build_importer_parents_from`, before calling `insert_parent_ref`, compute `real_name` from `pkg_name_version(&pkg.result).0` and only insert if `all_peer_dep_names.contains(&direct.alias) || all_peer_dep_names.contains(&real_name)`.
- (Optional) Consider adding similar gating where importer parents are constructed in `resolve_peers_workspace` too, if applicable.
- This keeps correctness but avoids inflating `ParentRefs` with entries that will never be consulted for peer resolution.

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

Description

External peer bubbling is filtered using children_map.contains_key(peer_alias), but peer_alias
is keyed by the peer dependency name (real package name). For npm-aliased children where install
alias differs from real name, this fails to absorb the peer at the child node and can reintroduce
spurious peer-suffix propagation.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R848-851]

+                if children_map.contains_key(&peer_alias) {
                    continue;
                }
                external_from_children.insert(peer_alias, peer_node_id);

Evidence

PR Compliance ID 1 requires name-keyed absorption of resolved peers when the node has a child with
the same package alias/name. The new code filters bubbling by checking
children_map.contains_key(peer_alias), but peers are recorded under peer_name in
resolve_one_peer, so a child installed under an npm alias will not match and the peer can
incorrectly bubble upward.

Align pacquet peer “bubble gate” behavior with pnpm (name-keyed absorption of peers listed as regular deps)
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[838-852]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1029-1032]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1045-1086]

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 peer absorption/bubbling filter checks only whether `children_map` contains the peer key (`children_map.contains_key(peer_alias)`), but peer keys are inserted using the peer dependency name (`peer_name`). This breaks name-keyed absorption when a child is present under an npm alias (install alias != real package name), allowing that peer to bubble upward.

## Issue Context
Compliance requires name-keyed absorption: if a node has a child with the same package alias/name, a resolved peer of that name must be considered internal and not bubbled. `children_map` is keyed by install alias, while peer resolution keys are `peer_name` (real name).

## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[838-852]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1029-1032]
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1045-1086]

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

Description

previously_resolved_children() iterates ancestors closest-first (iter().rev()) but merges with
BTreeMap::extend(), so later (farther) ancestors can overwrite the closest ancestor’s child NodeId
for the same alias. Since children edges are per-occurrence, this can record an incorrect dependency
edge and change the final graph/lockfile output in repeated-package ancestry cases.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R1471-1491]

+    fn previously_resolved_children(
+        &mut self,
+        parent_node_ids: &[NodeId],
+        parent_pkg_ids_chain: &[String],
+        current_pkg_id: &str,
+    ) -> BTreeMap<String, NodeId> {
+        let mut children = BTreeMap::new();
+        if !parent_pkg_ids_chain.iter().any(|pkg_id| pkg_id == current_pkg_id) {
+            return children;
+        }
+        for parent_node_id in parent_node_ids.iter().rev() {
+            let same_pkg = self
+                .tree
+                .dependencies_tree
+                .get(parent_node_id)
+                .is_some_and(|node| node.resolved_package_id == current_pkg_id);
+            if same_pkg {
+                children.extend(self.realize_children(parent_node_id));
+            }
+        }
+        children

Evidence

Children are explicitly per-occurrence, so overwriting the closest occurrence’s child edge with a
farther occurrence’s edge can produce a dependency edge that doesn’t match the current occurrence.
The merged children are then used when building the dependency graph and lockfile snapshot
dependencies, so a wrong edge changes outputs.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1471-1491]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[923-931]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[968-973]
pacquet/crates/resolving-deps-resolver/src/resolved_tree.rs[108-112]
pacquet/crates/package-manager/src/dependencies_graph_to_lockfile.rs[615-623]

Agent prompt

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

## Issue description
`previously_resolved_children()` merges children from multiple same-package ancestors using `BTreeMap::extend()` while iterating ancestors in reverse order (closest-first). This allows farther ancestors to overwrite the closest ancestor’s child mapping for the same alias, which is risky because dependency-tree children are per-occurrence and may differ.

## Issue Context
The merged children set is used to build `graph_children` / `record_edges`, which ultimately drives snapshot dependencies written into the lockfile.

## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1471-1491]

## Suggested fix
Change the merge semantics so the closest same-package ancestor wins on alias collisions:
- Option A (minimal): keep `iter().rev()` but insert with `entry().or_insert(...)` instead of `extend(...)` so earlier (closest) values are not overwritten.
- Option B: iterate from farthest-to-closest (remove `.rev()`) so that closer ancestors overwrite farther ones.

Add/adjust a focused unit test that constructs a repeated-package ancestry where two same-package ancestors have different per-occurrence children for the same alias, and assert that the chosen child comes from the closest ancestor.

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

• ❄️ 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.