git ls-remote runs once per workspace project for the same git dependency #16899

Verify latest release

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

pnpm version

12.11.2 (also reproduced with 12.8.2)

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

Dependencies resolver

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

No public reproduction yet. The dependency is in a private GitHub repository. A small test workspace with the same setup (24 projects using the same dependency through catalog:) makes only one git ls-remote call, so something else in our monorepo is also needed to trigger it, and we haven't found what. We can run a debug build or collect logs if that helps.

Reproduction steps

1. In a workspace, have several projects depend on the same git-hosted package pinned to a tag, through the default catalog:

   # pnpm-workspace.yaml
   catalog:
     '@scope/private-package': 'github:<org>/<private-repo>#v1.0.0'

   // package.json of each project (24 projects in our case)
   "devDependencies": {
     "@scope/private-package": "catalog:"
   }

2. Run pnpm install, so node_modules and pnpm-lock.yaml are up to date. The lockfile records the package as git+https://github.com/<org>/<private-repo>.git#<commit>.

3. Run an install that has to re-resolve the lockfile. Passing any pnpmfile does it, even an empty one:

   echo 'module.exports = { hooks: {} };' > /tmp/empty-pnpmfile.cjs
   rm node_modules/.pnpm-workspace-state-v1.json
   pnpm_config_pnpmfile=/tmp/empty-pnpmfile.cjs pnpm install

   autoDedupe: true has the same effect.

4. Watch the git processes pnpm starts (for example, with a git wrapper script first in PATH that logs its arguments).

Describe the Bug

pnpm resolves the tag with git ls-remote once for every project that depends on the package: 24 calls for the same repository and tag, one after another. They happen after the package has already been resolved and fetched:

time    git command
 0.03s  ls-remote -- https://github.com/<org>/<private-repo>.git v1.0.0 v1.0.0^{}
 4.37s  fetch --depth 1 origin <commit>
 7.29s  ls-remote -- https://github.com/<org>/<private-repo>.git v1.0.0 v1.0.0^{}
 8.45s  ls-remote -- https://github.com/<org>/<private-repo>.git v1.0.0 v1.0.0^{}
 9.66s  ls-remote -- https://github.com/<org>/<private-repo>.git v1.0.0 v1.0.0^{}
  ...   (the same call again, about every 1.1s)
32.32s  ls-remote -- https://github.com/<org>/<private-repo>.git v1.0.0 v1.0.0^{}

Each call takes about 1s, so the install takes about 30s instead of a few seconds. pnpm uses almost no CPU during that time and just waits on git.

What we checked:

• --offline still makes the calls and takes the same time.
• Changing minimumReleaseAge, blockExoticSubdeps, autoInstallPeers or shamefullyHoist makes no difference.
• --frozen-lockfile makes no calls and takes 0.5s.
• Workaround: pinning the dependency to the full commit SHA (#<commit SHA>) instead of the tag removes the calls, and the install takes about 7.5s.

Expected Behavior

pnpm resolves a repository#tag to a commit at most once per install and reuses the result for every project that depends on it. Ideally, it skips the lookup entirely when the lockfile already records the commit for that specifier. The install time shouldn't grow with the number of projects that use the dependency.

Which Node.js version are you using?

24.15.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)

N/A

Contributing a fix

• I am working on a fix