--offline resolution parses every version of every package once the store has an index (since 12.8.0) #16495

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

12.8.2 (first bad 12.8.0, last good 12.7.0)

Which area(s) of pnpm are affected? (leave empty if unsure)

Dependencies resolver, Store

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

Any --offline run that has to resolve, against a store that has an index.db but lacks the version a range picks. An empty index.db is enough, and the first --offline or --lockfile-only run creates one.

1. Serve 10 synthetic packuments synth-0 to synth-9, each listing 1,500 versions (0.0.0 to 29.0.49); no tarballs needed.
2. A project depends on all ten with ^5.0.0, registry set to that server.
3. pnpm install --lockfile-only once to fill the metadata cache. This also creates <store>/v11/index.db, with no rows.
4. rm pnpm-lock.yaml, then /usr/bin/time -l pnpm install --offline --lockfile-only, once against that store and once against a fresh store dir with no index.db.

The two runs write byte-identical lockfiles.

Describe the Bug

Since 12.8.0, an offline range pick whose chosen version is not in the store parses every version manifest in the packument and looks up each one in the store index, including versions the range can never select. That makes offline resolution about twice as expensive in instructions and memory on the synthetic repro, and about 3x on a real 109-dependency project.

Measured on macOS arm64 with the published binaries (instructions retired and max RSS from /usr/bin/time -l):

On the integrated-benchmark alotta-modules fixture (1,140 packuments, 68,779 versions), install --offline --lockfile-only with an empty index costs 2.47-2.51 G instructions on 12.7.0 and 7.25-7.35 G on 12.8.0. Linux x64, 12.8.2: 0.48 s wall without an index, 2.08 s with an empty one.

Cause: #15860 added OfflineStoreView::narrowed, called from pick_from_meta_offline whenever the picked version is not held. Its compute iterates meta.versions.iter(), which hydrates every lazy version fragment, and builds a store key for each. pnpm 11's findStoreHeldVersions checks the range before it touches a version, so pnpm 11 costs the same with or without an index.

Expected Behavior

The store-held fallback only reads and probes the versions the range admits, so an offline resolve costs about the same with or without a store index, as in 12.7.0.

Which Node.js version are you using?

24.21.0

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

x64 VM, 4 vCPU

Contributing a fix

• I am working on a fix

Written by an agent (Claude Code, Opus 5.5).