Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91dd0c4f-bfa9-4532-a778-9636ddbeb7e0

Reviewing files that changed from the base of the PR and between 90a685c and 25bffbb.

• .changeset/deterministic-shared-children-resolution.md
• installing/deps-resolver/src/resolveDependencies.ts
• installing/deps-resolver/src/resolveDependencyTree.ts
• installing/deps-resolver/test/resolveDependencyTree.test.ts
• pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs
• pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs
• pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs
• pacquet/crates/resolving-deps-resolver/src/resolve_peers/tests.rs
• pacquet/crates/resolving-deps-resolver/src/resolve_workspace.rs
• pacquet/crates/resolving-deps-resolver/src/tests.rs

• Create stacked PR
• Commit on current branch

• Create PR with unit tests
• Commit unit tests in branch fix/12358

Description

make_non_owner_nodes_lazy() clones the entire node→parentIds map and then iterates the full
dependencies tree on each ownership update, which can become quadratic and adds significant memory
churn for large workspaces.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R1415-1428]

+fn make_non_owner_nodes_lazy(ctx: &TreeCtx, pkg_id: &str, owner_node_id: &NodeId) {
+    let parent_ids_by_node = lock_recoverable(&ctx.workspace.node_parent_ids_by_id).clone();
+    let mut tree = lock_recoverable(&ctx.workspace.dependencies_tree);
+    for (node_id, node) in tree.iter_mut() {
+        if node_id == owner_node_id || node.resolved_package_id != pkg_id {
+            continue;
+        }
+        let Some(parent_ids) = parent_ids_by_node.get(node_id) else {
+            continue;
+        };
+        node.children =
+            crate::resolved_tree::TreeChildren::Lazy { parent_ids: Arc::clone(parent_ids) };
+    }
+}

Evidence

The new helper explicitly clones the full node_parent_ids_by_id map and then performs a complete
dependencies_tree iteration; it is invoked on ownership confirmation, so the scan can happen
repeatedly during resolution.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1415-1428]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1357-1359]

Agent prompt

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

## Issue description
On each ownership confirmation, `make_non_owner_nodes_lazy()` clones `node_parent_ids_by_id` and then scans the entire `dependencies_tree` to relabel non-owner occurrences as `Lazy`. This is an O(tree_size) operation that can repeat many times, compounding runtime and memory overhead.
### Issue Context
This relazy operation only needs to touch nodes whose `resolved_package_id == pkg_id` (and excluding the owner node). Scanning everything is unnecessary once you have an index.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1357-1359]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1415-1428]
### Suggested approach
- Maintain an index `pkg_id -> Vec<NodeId>` (or `HashSet<NodeId>`) for occurrences in `WorkspaceTreeCtx`.
- Update it whenever a node is inserted/updated in `dependencies_tree`.
- Rework `make_non_owner_nodes_lazy()` to iterate only the occurrence NodeIds for that `pkg_id`.
- Avoid cloning the whole `node_parent_ids_by_id` map:
- Look up `parent_ids` for each target node directly from the map (or store `parent_ids` on the tree node itself so the relazy update doesn’t need a second map).
- Keep the locking strategy safe (minimize lock hold time; avoid nested locks if possible).

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

Description

resolveDependency() now waits on a global depth barrier before calling
storeController.requestPackage(), which can serialize network/cache work across the whole workspace
and slow installs on large graphs. The barrier is held for the full resolveDependency() duration,
further extending the critical section beyond the ownership-claim logic the PR is trying to order.

Code

installing/deps-resolver/src/resolveDependencies.ts[R1668-1671]

+  const finishPackageResolution = startPackageResolution(ctx, options.currentDepth)
try {
-    const calcSpecifier = options.currentDepth === 0
-    if (!options.update && currentPkg.version && currentPkg.pkgId?.endsWith(`@${currentPkg.version}`) && !calcSpecifier) {
-      wantedDependency.bareSpecifier = replaceVersionInBareSpecifier(wantedDependency.bareSpecifier, currentPkg.version, ctx.namedRegistryPrefixes)
-    }
-    pkgResponse = await ctx.storeController.requestPackage(wantedDependency, {
-      allowBuild: ctx.allowBuild,
-      alwaysTryWorkspacePackages: ctx.linkWorkspacePackagesDepth >= options.currentDepth,
-      currentPkg: currentPkg
-        ? {
-          id: currentPkg.pkgId,
-          name: currentPkg.name,
-          resolution: currentPkg.resolution,
-          version: currentPkg.version,
-          publishedAt: currentPkg.pkgId ? ctx.wantedLockfile.time?.[currentPkg.pkgId] : undefined,
-        }
-        : undefined,
-      expectedPkg: currentPkg,
-      defaultTag: ctx.defaultTag,
-      ignoreScripts: ctx.ignoreScripts,
-      publishedBy: options.publishedBy,
-      publishedByExclude: ctx.publishedByExclude,
-      pickLowestVersion: options.pickLowestVersion,
-      downloadPriority: -options.currentDepth,
-      lockfileDir: ctx.lockfileDir,
-      preferredVersions,
-      preferWorkspacePackages: ctx.preferWorkspacePackages,
-      projectDir: (
-        options.currentDepth > 0 &&
-        !wantedDependency.bareSpecifier.startsWith('file:')
-      )
-        ? ctx.lockfileDir
-        : options.parentPkg.rootDir,
-      skipFetch: ctx.dryRun,
-      trustPolicy: ctx.trustPolicy,
-      trustPolicyExclude: ctx.trustPolicyExclude,
-      trustPolicyIgnoreAfter: ctx.trustPolicyIgnoreAfter,
-      update: options.update,
-      updateChecksums: options.updateChecksums,
-      workspacePackages: ctx.workspacePackages,
-      supportedArchitectures: options.supportedArchitectures,
-      onFetchError: (err: any) => { // eslint-disable-line
-        err.prefix = options.prefix
-        err.pkgsStack = getPkgsInfoFromIds(options.parentIds, ctx.resolvedPkgsById)
-        return err
-      },
-      injectWorkspacePackages: ctx.injectWorkspacePackages,
-      calcSpecifier,
-      pinnedVersion: options.pinnedVersion,
-    })
-  } catch (err: any) { // eslint-disable-line
-    const wantedDependencyDetails = {
-      name: wantedDependency.alias,
-      bareSpecifier: wantedDependency.bareSpecifier,
-      version: wantedDependency.alias ? wantedDependency.bareSpecifier : undefined,
-    }
-    if (wantedDependency.optional && err.code !== 'ERR_PNPM_TRUST_DOWNGRADE') {
-      skippedOptionalDependencyLogger.debug({
-        details: err.toString(),
-        package: wantedDependencyDetails,
-        parents: getPkgsInfoFromIds(options.parentIds, ctx.resolvedPkgsById),
-        prefix: options.prefix,
-        reason: 'resolution_failure',
+    await waitForPackageResolutionTurn(ctx, options.currentDepth)
+

Evidence

The barrier is acquired at the start of resolveDependency(), then blocks on shallower depths before
requestPackage(), and is only released in the function’s finalizer—so it serializes the most
expensive I/O step (package requests) and the rest of resolveDependency’s async work across depths.

installing/deps-resolver/src/resolveDependencies.ts[1668-1728]
installing/deps-resolver/src/resolveDependencies.ts[2038-2040]

Agent prompt

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

## Issue description
`resolveDependency()` currently gates *all* package resolution work at depth `d` behind completion of any active work at shallower depths, because it awaits `waitForPackageResolutionTurn()` before `requestPackage()`, and holds the barrier until the end of `resolveDependency()`.
This reduces parallelism (especially packument/tarball fetch overlap) and can slow down real-world installs, even though determinism is already enforced by the `(depth, importer order, parent path)` ownership comparison + takeover machinery.
### Issue Context
The determinism goal is to make shared-children ownership independent of async timing. That can be achieved without globally ordering *fetch/resolve* across depths: you can allow `requestPackage()` to run concurrently, then apply deterministic ownership selection when the `pkgId` is known (and only serialize the parts that must be consistent: ownership claim + shared children/missing-peer publication).
### Fix Focus Areas
- installing/deps-resolver/src/resolveDependencies.ts[1668-1671]
- installing/deps-resolver/src/resolveDependencies.ts[1049-1073]
Concretely, consider one of:
- Move `await waitForPackageResolutionTurn(...)` to just before `claimChildrenResolution(...)` / shared-children publication (after `pkgResponse.body.id` is known), so fetches stay parallel.
- Or remove the barrier entirely and rely on `claimChildrenResolution()` + takeover + node-updating logic for determinism (the compare/takeover path already exists).

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

Description

In resolveDependenciesOfDependency(), the early stale-owner short-circuit returns missing-peers
without calling resolveChildren(), so resolveChildren()’s stale handling
(setDependencyTreeNodeWithCurrentChildren) never runs and the occurrence may never be added to
ctx.dependenciesTree. Downstream code assumes ctx.dependenciesTree has an entry for every non-linked
dep.nodeId (ctx.dependenciesTree.get(dep.nodeId)!), so this can crash or yield an incomplete tree
when ownership flips between claim and postponedResolution execution.

Code

installing/deps-resolver/src/resolveDependencies.ts[R1008-1011]

  postponedResolution: async (postponedResolutionOpts) => {
+      if (!isCurrentChildrenResolution(ctx, resolveDependencyResult.pkgId, resolveDependencyResult.childrenResolutionId)) {
+        return resolveMissingPeersFromCurrentChildrenResolution(ctx, resolveDependencyResult.pkgId, postponedResolutionOpts.parentPkgAliases)
+      }

Evidence

The stale-owner pre-check returns without invoking resolveChildren (so no tree node is created
there), while owner occurrences also skip pendingNodes (which is the other mechanism used to
populate dependenciesTree). resolveDependencyTree later drains pendingNodes into dependenciesTree
and then dereferences dependenciesTree entries for direct deps with a non-null assertion, so missing
nodes can crash.

installing/deps-resolver/src/resolveDependencies.ts[994-1021]
installing/deps-resolver/src/resolveDependencies.ts[1314-1324]
installing/deps-resolver/src/resolveDependencies.ts[721-777]
installing/deps-resolver/src/resolveDependencies.ts[1935-2005]
installing/deps-resolver/src/resolveDependencyTree.ts[316-352]

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 package occurrence can lose children-ownership between `resolveDependency()` and the later `postponedResolution()` execution (because `resolveDependencies()` resolves deps in parallel, then runs all postponed resolutions). When that happens, `postponedResolution()` currently returns early on the stale check without calling `resolveChildren()`, which means the dependency-tree node for that occurrence is never created/updated.
Downstream, `resolveDependencyTree()` assumes `ctx.dependenciesTree` contains an entry for each non-linked `dep.nodeId` (it uses a non-null assertion), so missing entries can crash or produce an inconsistent tree.
## Issue Context
- `resolveChildren()` *does* handle staleness by calling `setDependencyTreeNodeWithCurrentChildren()`, but that logic is bypassed when `postponedResolution()` returns before calling `resolveChildren()`.
## Fix Focus Areas
- installing/deps-resolver/src/resolveDependencies.ts[1008-1015]
### Suggested fix
On the `postponedResolution` stale pre-check (`!isCurrentChildrenResolution(...)`), call the same fallback used inside `resolveChildren()`:
- `setDependencyTreeNodeWithCurrentChildren(ctx, { parentDepth: options.currentDepth, parentIds: [...options.parentIds, resolveDependencyResult.pkgId], parentPkg: resolveDependencyResult })`
Then return the missing-peers result.
This ensures the occurrence is represented in `ctx.dependenciesTree` even when it becomes a non-owner before its postponed resolution runs.

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

Description

In pacquet’s peers-cache hit path, cached missing peers (children + own) are re-emitted under
hoist-missing suppression keyed off first_walk_missing_by_pkg, but this PR now populates that map
from children-only missing_names_by_pkg. When chain_with_self includes the package itself,
cached own-peer misses can be suppressed because the owner’s children-only missing set will not
contain them, skewing hoist inputs and warnings.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[R624-627]

+        for (node_id, missing) in &self.node_missing_peers_of_children {
            let Some(tree_node) = self.tree.dependencies_tree.get(node_id) else { continue };
            missing_names_by_pkg
                .entry(tree_node.resolved_package_id.clone())

Evidence

The PR changes missing_names_by_pkg (and therefore first_walk_missing_by_pkg) to be
children-only, but the cache-hit branch still suppresses the full cached missing set
(missing_peers, which includes own misses). This mismatch makes it possible for own-peer misses to
be suppressed on cache hits when the package itself is part of the suppression chain.

pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[622-636]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[885-914]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[987-991]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[1094-1099]
pacquet/crates/resolving-deps-resolver/src/resolve_peers.rs[172-185]
pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[331-344]
pacquet/crates/resolving-deps-resolver/src/resolve_peers/tests.rs[146-195]

Agent prompt

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

### Issue description
On peers-cache hits, `resolve_peers` re-emits cached `missing_peers` (which is the union of children+own missing peers) but applies `missing_issue_suppressed(...)` using `first_walk_missing_by_pkg`, which this PR now fills from `missing_names_by_pkg` derived from **children-only** misses. This can incorrectly suppress a package’s **own** missing-peer diagnostics on cache-hit revisits during hoist passes.

### Issue Context
- `missing_names_by_pkg` is now constructed from `node_missing_peers_of_children` (children-only).
- The peers cache still stores:
 - `missing_peers` = children + own
 - `missing_peers_of_children` = children-only
- The cache-hit re-emission loop currently suppresses *all* entries in `missing_peers`, even those not present in `missing_peers_of_children`.

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

### Suggested fix
In the cache-hit branch, only apply `missing_issue_suppressed(...)` to cached misses that originate from children context (i.e. keys present in `missing_of_children` / `cached.missing_peers_of_children`). For cached misses that are *own-peer* misses (present in `missing` but not in `missing_of_children`), always emit them (no suppression) so hoist-time diagnostics match the intended “children-only suppression” model.

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

Description

updateChildrenResolutionNodes() linearly scans every recorded node context and is invoked after each
resolveChildren() completion, which can compound into O(N^2) work and noticeably slow resolution on
large graphs.

Code

installing/deps-resolver/src/resolveDependencies.ts[R1227-1237]

+function updateChildrenResolutionNodes (
+  ctx: ResolutionContext,
+  pkgId: PkgResolutionId,
+  currentNodeId: NodeId
+): void {
+  for (const [nodeId, nodeContext] of ctx.nodeResolutionContextByNodeId) {
+    if (nodeId === currentNodeId || nodeContext.pkgId !== pkgId) continue
+    const node = ctx.dependenciesTree.get(nodeId)
+    if (node == null || node.depth === -1) continue
+    node.children = () => buildTree(ctx, pkgId, nodeContext.parentIds, ctx.childrenByParentId[pkgId] ?? [], nodeContext.depth + 1, nodeContext.installable)
+  }

Evidence

The update function performs a full iteration over ctx.nodeResolutionContextByNodeId, and it is
called every time resolveChildren() finishes setting the node context, so the scan cost repeats
across many packages.

installing/deps-resolver/src/resolveDependencies.ts[1227-1237]
installing/deps-resolver/src/resolveDependencies.ts[1399-1406]

Agent prompt

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

## Issue description
`updateChildrenResolutionNodes()` iterates the entire `nodeResolutionContextByNodeId` map every time children are resolved, and is called unconditionally at the end of `resolveChildren()`. On large trees this produces repeated full scans and can become a major runtime cost.
### Issue Context
This scan is only needed to retarget *other occurrences* of the same `pkgId` when shared-children ownership changes. Doing a full-map scan for every owner-resolution is unnecessarily expensive.
### Fix Focus Areas
- installing/deps-resolver/src/resolveDependencies.ts[1227-1237]
- installing/deps-resolver/src/resolveDependencies.ts[1399-1406]
### Suggested approach
- Maintain an index from `pkgId -> Set<NodeId>` (or `pkgId -> NodeId[]`) in the resolution context.
- Update it wherever `nodeResolutionContextByNodeId.set(...)` is called.
- Change `updateChildrenResolutionNodes()` to iterate only the NodeIds for the given `pkgId`, rather than scanning the full map.
- Optionally, skip the update entirely when the set has size `<= 1` (no other occurrences to retarget).
- If possible, only invoke the update when ownership actually *changed* (e.g., `claimChildrenResolution` can return a `didTakeover`/`replacedExisting` flag).

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

Description

make_non_owner_nodes_lazy() clones the entire node→parentIds map and then iterates the full
dependencies tree on each ownership update, which can become quadratic and adds significant memory
churn for large workspaces.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R1415-1428]

+fn make_non_owner_nodes_lazy(ctx: &TreeCtx, pkg_id: &str, owner_node_id: &NodeId) {
+    let parent_ids_by_node = lock_recoverable(&ctx.workspace.node_parent_ids_by_id).clone();
+    let mut tree = lock_recoverable(&ctx.workspace.dependencies_tree);
+    for (node_id, node) in tree.iter_mut() {
+        if node_id == owner_node_id || node.resolved_package_id != pkg_id {
+            continue;
+        }
+        let Some(parent_ids) = parent_ids_by_node.get(node_id) else {
+            continue;
+        };
+        node.children =
+            crate::resolved_tree::TreeChildren::Lazy { parent_ids: Arc::clone(parent_ids) };
+    }
+}

Evidence

The new helper explicitly clones the full node_parent_ids_by_id map and then performs a complete
dependencies_tree iteration; it is invoked on ownership confirmation, so the scan can happen
repeatedly during resolution.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1415-1428]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1357-1359]

Agent prompt

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

## Issue description
On each ownership confirmation, `make_non_owner_nodes_lazy()` clones `node_parent_ids_by_id` and then scans the entire `dependencies_tree` to relabel non-owner occurrences as `Lazy`. This is an O(tree_size) operation that can repeat many times, compounding runtime and memory overhead.
### Issue Context
This relazy operation only needs to touch nodes whose `resolved_package_id == pkg_id` (and excluding the owner node). Scanning everything is unnecessary once you have an index.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1357-1359]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1415-1428]
### Suggested approach
- Maintain an index `pkg_id -> Vec<NodeId>` (or `HashSet<NodeId>`) for occurrences in `WorkspaceTreeCtx`.
- Update it whenever a node is inserted/updated in `dependencies_tree`.
- Rework `make_non_owner_nodes_lazy()` to iterate only the occurrence NodeIds for that `pkg_id`.
- Avoid cloning the whole `node_parent_ids_by_id` map:
- Look up `parent_ids` for each target node directly from the map (or store `parent_ids` on the tree node itself so the relazy update doesn’t need a second map).
- Keep the locking strategy safe (minimize lock hold time; avoid nested locks if possible).

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

Description

In resolveDependenciesOfDependency(), the early stale-owner short-circuit returns missing-peers
without calling resolveChildren(), so resolveChildren()’s stale handling
(setDependencyTreeNodeWithCurrentChildren) never runs and the occurrence may never be added to
ctx.dependenciesTree. Downstream code assumes ctx.dependenciesTree has an entry for every non-linked
dep.nodeId (ctx.dependenciesTree.get(dep.nodeId)!), so this can crash or yield an incomplete tree
when ownership flips between claim and postponedResolution execution.

Code

installing/deps-resolver/src/resolveDependencies.ts[R1008-1011]

   postponedResolution: async (postponedResolutionOpts) => {
+      if (!isCurrentChildrenResolution(ctx, resolveDependencyResult.pkgId, resolveDependencyResult.childrenResolutionId)) {
+        return resolveMissingPeersFromCurrentChildrenResolution(ctx, resolveDependencyResult.pkgId, postponedResolutionOpts.parentPkgAliases)
+      }

Evidence

The stale-owner pre-check returns without invoking resolveChildren (so no tree node is created
there), while owner occurrences also skip pendingNodes (which is the other mechanism used to
populate dependenciesTree). resolveDependencyTree later drains pendingNodes into dependenciesTree
and then dereferences dependenciesTree entries for direct deps with a non-null assertion, so missing
nodes can crash.

installing/deps-resolver/src/resolveDependencies.ts[994-1021]
installing/deps-resolver/src/resolveDependencies.ts[1314-1324]
installing/deps-resolver/src/resolveDependencies.ts[721-777]
installing/deps-resolver/src/resolveDependencies.ts[1935-2005]
installing/deps-resolver/src/resolveDependencyTree.ts[316-352]

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 package occurrence can lose children-ownership between `resolveDependency()` and the later `postponedResolution()` execution (because `resolveDependencies()` resolves deps in parallel, then runs all postponed resolutions). When that happens, `postponedResolution()` currently returns early on the stale check without calling `resolveChildren()`, which means the dependency-tree node for that occurrence is never created/updated.
Downstream, `resolveDependencyTree()` assumes `ctx.dependenciesTree` contains an entry for each non-linked `dep.nodeId` (it uses a non-null assertion), so missing entries can crash or produce an inconsistent tree.
## Issue Context
- `resolveChildren()` *does* handle staleness by calling `setDependencyTreeNodeWithCurrentChildren()`, but that logic is bypassed when `postponedResolution()` returns before calling `resolveChildren()`.
## Fix Focus Areas
- installing/deps-resolver/src/resolveDependencies.ts[1008-1015]
### Suggested fix
On the `postponedResolution` stale pre-check (`!isCurrentChildrenResolution(...)`), call the same fallback used inside `resolveChildren()`:
- `setDependencyTreeNodeWithCurrentChildren(ctx, { parentDepth: options.currentDepth, parentIds: [...options.parentIds, resolveDependencyResult.pkgId], parentPkg: resolveDependencyResult })`
Then return the missing-peers result.
This ensures the occurrence is represented in `ctx.dependenciesTree` even when it becomes a non-owner before its postponed resolution runs.

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

Description

updateChildrenResolutionNodes() linearly scans every recorded node context and is invoked after each
resolveChildren() completion, which can compound into O(N^2) work and noticeably slow resolution on
large graphs.

Code

installing/deps-resolver/src/resolveDependencies.ts[R1227-1237]

+function updateChildrenResolutionNodes (
+  ctx: ResolutionContext,
+  pkgId: PkgResolutionId,
+  currentNodeId: NodeId
+): void {
+  for (const [nodeId, nodeContext] of ctx.nodeResolutionContextByNodeId) {
+    if (nodeId === currentNodeId || nodeContext.pkgId !== pkgId) continue
+    const node = ctx.dependenciesTree.get(nodeId)
+    if (node == null || node.depth === -1) continue
+    node.children = () => buildTree(ctx, pkgId, nodeContext.parentIds, ctx.childrenByParentId[pkgId] ?? [], nodeContext.depth + 1, nodeContext.installable)
+  }

Evidence

The update function performs a full iteration over ctx.nodeResolutionContextByNodeId, and it is
called every time resolveChildren() finishes setting the node context, so the scan cost repeats
across many packages.

installing/deps-resolver/src/resolveDependencies.ts[1227-1237]
installing/deps-resolver/src/resolveDependencies.ts[1399-1406]

Agent prompt

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

### Issue description
`updateChildrenResolutionNodes()` iterates the entire `nodeResolutionContextByNodeId` map every time children are resolved, and is called unconditionally at the end of `resolveChildren()`. On large trees this produces repeated full scans and can become a major runtime cost.

### Issue Context
This scan is only needed to retarget *other occurrences* of the same `pkgId` when shared-children ownership changes. Doing a full-map scan for every owner-resolution is unnecessarily expensive.

### Fix Focus Areas
- installing/deps-resolver/src/resolveDependencies.ts[1...

• ➕ Eliminates async-timing sensitivity by design; ownership computed from a complete view.
• ➕ May reduce need for a per-depth barrier and mid-flight owner changes.
• ➖ Likely large refactor: requires storing intermediate graph + revisiting nodes.
• ➖ Higher memory footprint and risk; hard to keep performance parity.

• ➕ Centralizes ordering (depth/importer/path) without per-depth waiter recursion.
• ➕ Potentially easier to reason about fairness/starvation than ad-hoc barriers.
• ➖ More invasive concurrency model change; touches many call sites.
• ➖ Still must handle owner changes and cached children updates correctly.