Walkthrough

Resolve tree now seeds per-level preferred-version overlays by resolving direct children first, then walks grandchildren with a layered overlay; adds PreferredVersionsOverlay, threads it into resolver opts and npm pick logic, extends WantedKey caching, refactors node resolution to seed/pending, and updates importer hoist flow and tests.

Changes

Per-level preferred-versions overlay mechanism

Sequence Diagram(s)

sequenceDiagram
  participant TreeWalk as Dependency Tree Walk
  participant SeedResolver as resolve_node_seed
  participant Cache as WantedKey Cache
  participant NpmResolver as NPM Resolver

  rect rgba(200,150,255,0.5)
  Note over TreeWalk: Phase 1 — resolve all direct children to seed level overlay
  TreeWalk->>SeedResolver: resolve_node_seed(child, pick_overlay=None)
  SeedResolver->>Cache: lookup WantedKey(overlay_versions=[])
  Cache-->>SeedResolver: miss / hit
  SeedResolver->>NpmResolver: resolve (no overlay)
  NpmResolver-->>SeedResolver: NodeSeed::Done / NodeSeed::Pending
  SeedResolver-->>TreeWalk: collect seeds
  end

  rect rgba(150,200,255,0.5)
  Note over TreeWalk: Phase 2 — compute level_versions, layer overlay, walk grandchildren
  TreeWalk->>TreeWalk: compute level_versions -> layer overlay
  loop per-child's children
    TreeWalk->>SeedResolver: resolve_node_seed(grandchild, pick_overlay=layered)
    SeedResolver->>Cache: lookup WantedKey(overlay_versions=[...])
    Cache-->>SeedResolver: miss / hit
    SeedResolver->>NpmResolver: resolve (with merged overlay selectors)
    NpmResolver-->>SeedResolver: result respects sibling-preferred version
  end
  end

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• pnpm/pnpm#11874: Overlapping changes to caching/memoization in resolve_dependency_tree.rs.
• pnpm/pnpm#12128: Overlaps in WantedKey cache-key adjustments for resolution reuse.

"I'm a rabbit with a map of hops and codes,
I seed the level where sibling version bodes,
grandchildren follow with layered delight,
versions aligned, every subtree polite.
Hooray for overlays—hops and bytes tonight!"

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

• X
• Mastodon
• Reddit
• LinkedIn

Description

In resolve_wanted_cached, the code checks cache_key.7.is_empty(), but WantedKey element 7 is
prior_key: Option<PkgNameVerPeer>, so this is a type error and prevents compilation. The overlay
guard should check the overlay_versions Vec field (index 8) instead.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R1662-1670]

+    let overlay_opts;
+    let opts = if cache_key.7.is_empty() {
+        opts
+    } else {
+        let mut owned = opts.clone();
+        owned.preferred_versions_overlay = pick_overlay.map(Arc::clone);
+        overlay_opts = owned;
+        &overlay_opts
+    };

Evidence

WantedKey’s 8th element (index 7) is an Option<PkgNameVerPeer>, while the overlay versions are
stored in the 9th element (index 8), so calling is_empty() on cache_key.7 is a compile-time type
mismatch.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[456-466]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1646-1670]

Agent prompt

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

## Issue description
`resolve_wanted_cached` uses `cache_key.7.is_empty()` to decide whether to clone `ResolveOptions` to attach `preferred_versions_overlay`, but tuple field 7 is `prior_key: Option<PkgNameVerPeer>`.
### Issue Context
`WantedKey` was extended to include `overlay_versions` as the last element; the guard should inspect that Vec (index 8).
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[456-466]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1662-1670]
### Suggested change
- Replace `cache_key.7.is_empty()` with `cache_key.8.is_empty()` (or, more readably, destructure `cache_key` and check the `overlay_versions` element).

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

Description

warm_children_resolutions constructs a WantedKey tuple with only 8 elements even though WantedKey
now has 9 elements (it includes prior_key and overlay_versions). This is a build-breaking type
mismatch in the warmup path.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R1768-1780]

+                let project_scope = is_project_relative_specifier(wanted.bare_specifier.as_deref())
+                    .then(|| ctx.base_opts.project_dir.clone());
+                let cache_key: WantedKey = (
+                    wanted.alias.clone(),
+                    wanted.bare_specifier.clone(),
+                    wanted.optional,
+                    wanted.injected,
+                    opts.pick_lowest_version,
+                    opts.published_by,
+                    project_scope,
+                    Vec::new(),
+                );
+                let _ = resolve_wanted_cached(ctx, resolver, &wanted, opts, None, cache_key).await;

Evidence

WantedKey is defined with 9 elements, but the warmup path’s tuple literal only supplies 8, omitting
the prior_key field entirely.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[456-466]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1751-1785]

Agent prompt

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

## Issue description
`warm_children_resolutions` creates a `WantedKey` tuple that no longer matches the `WantedKey` type alias after it was extended to include `(prior_key, overlay_versions)`.
### Issue Context
This code path is not behind a cfg gate; the crate won’t compile until the tuple matches the updated alias.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[456-466]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1768-1780]
### Suggested change
Update the warmup cache key to include both trailing fields, e.g.:

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

Description

resolve_node_seed flattens overlay versions across multiple possible lookup names into a single
sorted Vec that becomes part of the resolved_by_wanted cache key, so different overlays can produce
the same key and incorrectly reuse a prior pick. This is incorrect because the npm resolver consults
preferred_versions_overlay by the resolved package name (spec.name), so the per-name distribution of
overlay versions matters, not just the union.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R1154-1165]

+    let overlay_versions: Vec<String> = pick_overlay
+        .as_ref()
+        .map(|overlay| {
+            let mut versions: Vec<String> = overlay_lookup_names(&wanted)
+                .iter()
+                .flat_map(|name| overlay.versions_for(name))
+                .map(str::to_string)
+                .collect();
+            versions.sort_unstable();
+            versions.dedup();
+            versions
+        })

Evidence

The cache key currently stores only a sorted union of overlay versions across multiple names, but
the overlay is consumed by the npm picker for a single resolved name (spec.name). Therefore two
overlays with different per-name version sets can collide in the cache and reuse the wrong resolve
result.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1148-1176]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1540-1579]
pacquet/crates/resolving-npm-resolver/src/preferred_overlay.rs[12-26]
pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs[361-375]

Agent prompt

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

## Issue description
`resolve_node_seed` builds `overlay_versions` as a *union* of overlay versions across `overlay_lookup_names(&wanted)` and stores only that union in the `WantedKey`. Because the actual picker consults the overlay under a specific resolved name (`spec.name`), two different overlay states can collapse to the same cache key and cause a resolve result (picked version) computed under the “wrong” overlay to be reused.
## Issue Context
This happens when `overlay_lookup_names()` returns more than one name (alias + npm inner + jsr folded name). The current cache key representation loses which versions came from which name.
Concrete collision shape:
- Overlay A: versions_for("inner") = ["1.0.0"], versions_for("alias") = ["2.0.0"] → union ["1.0.0","2.0.0"]
- Overlay B: versions_for("inner") = ["2.0.0"], versions_for("alias") = ["1.0.0"] → union ["1.0.0","2.0.0"]
If the resolver consults the overlay under "inner" (via `spec.name`), Overlay A and B can produce different picks but collide in the cache.
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1148-1190]
Suggested implementation direction:
- Replace `overlay_versions: Vec<String>` with a stable, name-associated structure in the cache key, e.g. `Vec<(String, Vec<String>)>` or `BTreeMap<String, Vec<String>>`, where:
- each lookup name is included explicitly,
- its versions list is sorted/deduped,
- the outer collection is sorted by name.
- Use that same structure both to decide whether the overlay is “empty” (no relevant entries) and to key `resolved_by_wanted`.
- Keep the existing fast path (no overlay in key/options) when the per-name structure is empty.

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

Description

overlay_lookup_names() only derives overlay lookup keys for the manifest alias, npm: aliases, and
jsr: specifiers, so named-registry specifiers like gh:@scope/pkg@^1 won’t include the resolved
package name (@scope/pkg). When that happens, resolve_wanted_cached() treats the overlay as empty
and does not pass preferred_versions_overlay into the resolver, so named-registry version picking
won’t see the per-level fold and may reuse an overlay-insensitive resolved_by_wanted cache entry.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R1492-1564]

+/// The package names the npm picker may consult the preferred-versions
+/// overlay under for one wanted edge: the alias itself, plus the inner
+/// target of an `npm:` alias and the folded `@jsr/...` name of a
+/// `jsr:` specifier — mirroring the name derivation in the npm
+/// resolver's `parse_bare_specifier`, which keys its overlay merge by
+/// the resolved `spec.name` rather than the outer alias.
+fn overlay_lookup_names(wanted: &WantedDependency) -> Vec<String> {
+    let mut names: Vec<String> = Vec::new();
+    if let Some(alias) = wanted.alias.as_deref()
+        && !alias.is_empty()
+    {
+        names.push(alias.to_string());
+    }
+    let Some(bare) = wanted.bare_specifier.as_deref() else { return names };
+    if let Some(rest) = bare.strip_prefix("npm:") {
+        let alias_keeps_name = wanted
+            .alias
+            .as_deref()
+            .is_some_and(|alias| !alias.is_empty() && rest.parse::<node_semver::Range>().is_ok());
+        if !alias_keeps_name {
+            let last_at =
+                rest.bytes().enumerate().rev().find_map(|(i, b)| (b == b'@').then_some(i));
+            let inner = match last_at {
+                Some(idx) if idx >= 1 => &rest[..idx],
+                _ => rest,
+            };
+            if !inner.is_empty() && !names.iter().any(|name| name == inner) {
+                names.push(inner.to_string());
+            }
+        }
+    } else if bare.starts_with("jsr:")
+        && let Ok(Some(spec)) = pacquet_resolving_jsr_specifier_parser::parse_jsr_specifier(
+            bare,
+            wanted.alias.as_deref(),
+        )
+        && !names.contains(&spec.npm_pkg_name)
+    {
+        names.push(spec.npm_pkg_name);
+    }
+    names
+}
+
+/// Look the wanted edge up in the per-wanted dedup cache or run the
+/// resolver chain and the manifest-hook pipeline, caching the
+/// `Arc<ResolveResult>` under `cache_key`. Concurrent first-callers
+/// can both miss and resolve in parallel — the resolver's own
+/// per-cache-key fetch locker coalesces the network work, and the
+/// second `or_insert` loses the race harmlessly.
+async fn resolve_wanted_cached<Chain>(
+    ctx: &TreeCtx,
+    resolver: &Chain,
+    wanted: &WantedDependency,
+    opts: &ResolveOptions,
+    pick_overlay: Option<&Arc<PreferredVersionsOverlay>>,
+    cache_key: WantedKey,
+) -> Result<Arc<pacquet_resolving_resolver_base::ResolveResult>, ResolveDependencyTreeError>
+where
+    Chain: Resolver + ?Sized,
+{
+    let cached =
+        lock_recoverable(&ctx.workspace.resolved_by_wanted).get(&cache_key).map(Arc::clone);
+    if let Some(result) = cached {
+        return Ok(result);
+    }
+    let overlay_opts;
+    let opts = if cache_key.7.is_empty() {
+        opts
+    } else {
+        let mut owned = opts.clone();
+        owned.preferred_versions_overlay = pick_overlay.map(Arc::clone);
+        overlay_opts = owned;
+        &overlay_opts
+    };

Evidence

The deps-resolver derives overlay lookup names from the wanted edge, and only enables overlay
passing when that derived overlay-view is non-empty; however, named-registry parsing can produce a
resolved package name from the specifier body that differs from the manifest alias, and the
named-registry resolver consults overlays under that resolved name, so the overlay can be skipped
entirely.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1492-1564]
pacquet/crates/resolving-npm-resolver/src/parse_bare_specifier.rs[201-286]
pacquet/crates/resolving-npm-resolver/src/named_registry_resolver.rs[195-216]

Agent prompt

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

## Issue description
`overlay_lookup_names()` does not include the resolved package name for named-registry specifiers (`<registryAlias>:<pkgName>@<selector>`). Because `resolve_wanted_cached()` only passes `preferred_versions_overlay` to the resolver when the overlay-view portion of the cache key is non-empty, named-registry edges can incorrectly resolve without the per-level preferred-version overlay.
### Issue Context
Named-registry resolution consults the overlay using the *resolved* `spec.name` (not the manifest alias). Therefore, if the overlay name-derivation misses that `spec.name`, the overlay won’t be applied and the cache key won’t distinguish overlay-sensitive vs overlay-insensitive resolutions.
### Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1492-1564]
Suggested implementation direction:
- Extend `overlay_lookup_names()` to also derive the inner package name for `:<body>` specifiers (named registry), similar to the logic in `parse_named_registry_specifier_to_registry_package_spec`:
- If `bare` contains `:` and is not a known protocol that shouldn’t use npm picking (`link:`, `file:`, `workspace:`, `npm:`, `jsr:`, `http(s)://`), parse the body to extract the package name portion (scoped/unscoped) and include it in the returned names.
- Ensure the extracted name is de-duplicated against existing entries.
- Add a small regression test analogous to the `npm_alias_child_consults_overlay_by_inner_name` test, but for a named-registry dependency where alias != resolved name, asserting the overlay is visible under the resolved name.

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

Description

extend_tree/walk_node_children await warm_children_resolutions, and warm_children_resolutions awaits
join_all over child resolves, so the phase-1 sibling barrier can be extended by warmup work rather
than being purely opportunistic overlap. This can increase install critical-path latency (and
network/CPU load) on large graphs where warmups outlast the slowest sibling seed resolution.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[R968-973]

+                let base_overlay = ctx.base_opts.preferred_versions_overlay.clone();
+                let seed =
+                    resolve_node_seed(ctx, resolver, wanted, &[], 0, false, reuse, base_overlay)
+                        .await?;
+                warm_children_resolutions(ctx, resolver, &seed).await;
+                Ok::<NodeSeed, ResolveDependencyTreeError>(seed)

Evidence

The seed phase awaits warm_children_resolutions before returning each seed future, and the warm
helper itself awaits join_all of child resolves; the doc comment explicitly states the goal is
overlap while the barrier waits, which isn’t true when the warm futures extend the barrier.

pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[940-1000]
pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1618-1670]

Agent prompt

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

## Issue description
`warm_children_resolutions` is intended as speculative overlap, but it is awaited from the seed phase and itself awaits `join_all`, so it can become part of the phase barrier and extend critical-path latency.
## Issue Context
Because `extend_tree`/`walk_node_children` run a two-phase “postponed-resolution barrier” (resolve all seeds, then walk), any extra awaited work inside the seed futures delays the barrier completion.
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[940-999]
- pacquet/crates/resolving-deps-resolver/src/resolve_dependency_tree.rs[1618-1670]
## Suggested fix
- If the intent is truly speculative warming: refactor so warmups are not awaited on the phase-1 critical path (e.g., enqueue/spawn warm tasks and let them run concurrently while phase 2 begins). This likely requires making the warm tasks own/clone what they need (or routing through a shared/background fetch queue) so they can outlive the stack frame.
- If you intentionally want to await warmups to maximize cache hits: update the doc comment to reflect that warmups are part of the barrier, and consider bounding the warmup work (limit concurrency and/or apply a timeout) so it can’t dominate phase-1 runtime.

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

Description

overlay_merged_selectors clones the full per-package VersionSelectors map whenever the overlay
contributes versions for a name, allocating and copying even when only a few overlay versions need
to be added. This happens in the npm resolver pick hot path and can add noticeable allocation/CPU
overhead on large graphs with frequent overlay hits.

Code

pacquet/crates/resolving-npm-resolver/src/preferred_overlay.rs[R12-26]

+pub(crate) fn overlay_merged_selectors(
+    opts: &ResolveOptions,
+    name: &str,
+) -> Option<VersionSelectors> {
+    let versions = opts.preferred_versions_overlay.as_ref()?.versions_for(name);
+    if versions.is_empty() {
+        return None;
+    }
+    let mut selectors = opts.preferred_versions.get(name).cloned().unwrap_or_default();
+    for version in versions {
+        selectors
+            .entry(version.to_string())
+            .or_insert(VersionSelectorEntry::Plain(VersionSelectorType::Version));
+    }
+    Some(selectors)

Evidence

The overlay helper clones the selector map on overlay hits, and both the named-registry and npm
resolvers call it per registry pick and then pass the merged selectors into PickPackageOptions.

pacquet/crates/resolving-npm-resolver/src/preferred_overlay.rs[1-27]
pacquet/crates/resolving-npm-resolver/src/named_registry_resolver.rs[195-216]
pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs[361-382]

Agent prompt

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

## Issue description
When an overlay hit occurs, `overlay_merged_selectors()` clones `opts.preferred_versions.get(name)` into a new `VersionSelectors` map and inserts overlay versions into it. This creates per-resolve allocations and copies on a hot path.
## Issue Context
The callers invoke this for each registry pick and then pass the owned merged map into the picker.
## Fix Focus Areas
- pacquet/crates/resolving-npm-resolver/src/preferred_overlay.rs[1-27]
- pacquet/crates/resolving-npm-resolver/src/named_registry_resolver.rs[195-216]
- pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs[361-382]
## Suggested fix
- Avoid materializing a merged `VersionSelectors` map. Instead, pass overlay versions separately down into the picker (e.g., extend `PickPackageOptions` / `PickPackageFromMetaOptions` with `preferred_overlay_versions: Option<Vec<&str>>` or an iterator) and have `prioritize_preferred_versions()` add overlay versions directly to the prioritizer with weight=1.
- If you must materialize: consider caching merged selectors per `(overlay_layer_id, name)` (where `overlay_layer_id` is derived from `Arc::as_ptr`) to amortize repeated clones within the same subtree level.

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

Description

The ResolveImporterOptions::all_preferred_versions field docs say optional-peer hoisting reads a
snapshot taken before run-resolved versions are folded in, but ImporterHoistState updates
all_preferred_versions before hoist_optional_round consults it. This mismatch is misleading for
future maintenance/tests of hoist behavior.

Code

pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[R399-408]

+        // Both hoists read the run-extended preferred-versions map:
+        // upstream folds every resolved package's version into
+        // `ctx.allPreferredVersions`
+        // ([`resolveDependencies.ts#L1483-L1488`](https://github.com/pnpm/pnpm/blob/01b3d45ddb/installing/deps-resolver/src/resolveDependencies.ts#L1483-L1488))
+        // and consults it for the optional hoist after each wave.
+        // Refreshed per round so it carries every importer's versions,
+        // not just this importer's.
+        update_preferred_versions_with_ctx(&self.ctx, &mut self.all_preferred_versions);
+        // The hoist input must not see missing peers declared inside a
+        // subtree first resolved under an earlier importer — upstream

Evidence

The docs explicitly state optional hoisting reads a snapshot before run-resolved versions are folded
in, but the implementation updates all_preferred_versions in run_required_round and then uses
that same map in hoist_optional_round.

pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[78-92]
pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[399-406]
pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[493-508]

Agent prompt

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

## Issue description
`ResolveImporterOptions::all_preferred_versions` documentation claims optional-peer hoisting uses a pre-fold snapshot, but the current control flow updates `all_preferred_versions` (via `update_preferred_versions_with_ctx`) before `get_hoistable_optional_peers` is called.
## Issue Context
This is a docs/maintainability issue: the code is internally consistent, but the comment now contradicts the behavior after the hoist-round refactor.
## Fix Focus Areas
- pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[78-91]
- pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[399-408]
- pacquet/crates/resolving-deps-resolver/src/resolve_importer.rs[505-508]

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

• Resolve each sibling level before walking subtrees to match pnpm per-level preference folding.
• Thread a per-level preferred-version overlay into npm version picking and dedup cache keys.
• Add regression test ensuring children prefer a parent-level sibling’s resolved version.

The following are alternative approaches to this PR:

Recommendation: Current approach is the best tradeoff: it matches pnpm semantics via an explicit per-level barrier, keeps layering O(1) with Arc chaining, and preserves correctness by keying memoization on the overlay’s per-name view (while avoiding allocations when overlays don’t apply).

lib.rs Wire in preferred overlay helper module +1/-0

Wire in preferred overlay helper module

• Registers the new preferred_overlay module so npm resolver components can merge overlay selectors into the picker inputs.

pacquet/crates/resolving-npm-resolver/src/lib.rs

---

preferred_overlay.rs Merge overlay versions into preferred selectors +27/-0

Merge overlay versions into preferred selectors

• Introduces overlay_merged_selectors(opts, name) that converts overlay versions into plain 'version' selectors and merges them with any existing preferred selectors. Avoids allocations when the overlay has no entries for the name.

pacquet/crates/resolving-npm-resolver/src/preferred_overlay.rs

---

lib.rs Re-export PreferredVersionsOverlay from resolver-base +5/-5

Re-export PreferredVersionsOverlay from resolver-base

• Exports the new PreferredVersionsOverlay type so downstream crates (deps-resolver, npm-resolver) can share a single definition.

pacquet/crates/resolving-resolver-base/src/lib.rs

---

resolve.rs Add PreferredVersionsOverlay type and ResolveOptions field +53/-0

Add PreferredVersionsOverlay type and ResolveOptions field

• Defines an Arc-chained PreferredVersionsOverlay with O(1) layering and per-name version lookup across the chain. Extends ResolveOptions with an optional preferred_versions_overlay used during tree walking (direct deps remain overlay-free).

pacquet/crates/resolving-resolver-base/src/resolve.rs

---

resolve_dependency_tree.rs Two-phase level walk and per-level preferred-version overlay +230/-13

Two-phase level walk and per-level preferred-version overlay

• Splits node processing into a seed phase (resolve + memoize + dedup) and a child-walk phase to enforce a sibling-level barrier before recursing. Builds a PreferredVersionsOverlay from each fully-resolved level and passes it to child picks; also adds overlay-derived data to the WantedKey to keep memoization correct across different overlays.

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

---

named_registry_resolver.rs Consult overlay-derived selectors during registry picks +5/-1

Consult overlay-derived selectors during registry picks

• Augments preferred_version_selectors to first consider overlay_merged_selectors(name), falling back to the static preferred_versions map when no overlay applies.

pacquet/crates/resolving-npm-resolver/src/named_registry_resolver.rs

---

npm_resolver.rs Consult overlay-derived selectors during npm picks +5/-1

Consult overlay-derived selectors during npm picks

• Mirrors the named_registry_resolver change: fold per-level overlay versions into the preferred selectors used by pick_package, with fallback to the static map.

pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs

---

tests.rs Regression test for per-level preferred version folding +122/-0

Regression test for per-level preferred version folding

• Adds a resolver stub that records the preferred_versions_overlay view at resolve time. Verifies importer-level direct deps see no overlay, while a child dependency sees a sibling-resolved pinned version in its overlay.

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

---

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