Optional peer dependencies from unrelated workspace devDependencies enter another package’s production graph

[SF97]

Verify latest release

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

pnpm version

12.9.1;11.28.3

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

https://github.com/SF97/pnpm-dedupe-peer-repro

Reproduction steps

Reproduction repository: https://github.com/SF97/pnpm-dedupe-peer-repro

Use pnpm 12.9.1, pinned in the repo. The same behavior was also verified with 11.28.3.

1. Clone the reproduction repository and enter it:

   git clone https://github.com/SF97/pnpm-dedupe-peer-repro.git
   cd pnpm-dedupe-peer-repro

2. Follow README step 1, including resetting pnpm-workspace.yaml to the default settings before the clean install. The checked-in configuration disables both settings, so this reset is required to reproduce the behavior.

3. Run pnpm --filter app why --prod node-forge. Although app declares only webpack, the production graph includes:

   app → webpack → webpack-cli → webpack-dev-server → selfsigned → node-forge
   

4. Follow README step 4 to disable only dedupePeerDependents, then reinstall from scratch and run the same app-filtered command. The chain still appears.

5. Follow README step 5 to disable both autoInstallPeers and dedupePeerDependents, then reinstall from scratch. The command now produces no output. node-forge remains only in tooling's development graph.

6. Follow README step 5 to disable both autoInstallPeers and dedupePeerDependents, then reinstall from scratch. The command now produces no output. node-forge remains only in tooling's development graph.
   The README includes all five control configurations. On both tested pnpm versions, defaults and either setting disabled alone expose the chain; excluding tooling or disabling both settings removes it from app's production graph.

Describe the Bug

Adding an unrelated workspace package with Webpack CLI/dev-server in its devDependencies changes another package's production dependency graph. app declares only webpack, but its resolved Webpack instance gains the optional webpack-cli peer, exposing webpack-dev-server, selfsigned, and node-forge under --prod.

This occurs on pnpm 11.28.3 and 12.9.1, including when dedupePeerDependents: false. Disabling both autoInstallPeers and dedupePeerDependents, or excluding the unrelated tooling package, removes that chain from app without changing its manifest.

I understand that dedupePeerDependents can share instances with optional peers. However, here the peer is supplied only by an unrelated workspace package's devDependencies, yet its dependency chain becomes reachable from app under --prod. This also occurs with dedupePeerDependents: false. This production/development boundary crossing doesn't make sense to me.

Expected Behavior

Including or excluding an unrelated workspace package's development tooling should not change app's production dependency closure. I would expect node-forge to remain reachable only through tooling's development dependencies, and pnpm --filter app why --prod node-forge to produce no output, with any of the configuration combinations provided.

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)

Ubuntu

Contributing a fix

• I am working on a fix

[zkochan]

This is not a bug at the moment. This is a choice. Changing how this works is a design question.

[sergio-ferreira-jscrambler]

This is not a bug at the moment. This is a choice. Changing how this works is a design question.

Thank you for clarifying that. I think it's worth changing, but I understand that there may be some compelling arguments in favor of staying how is it. Where can I find the documentation for those arguments, so I can read them and analyze? If I want to propose a design change should I make a PR to https://github.com/pnpm/rfcs ?

[olexiyb]

Workaround that worked for us (AdonisJS monorepo, pnpm 12.8.2)

Same shape of problem: @adonisjs/core, auth, session and friends declare @adonisjs/assembler and @japa/* as optional peers. Our apps install them as devDependencies, pnpm wires the peers to those copies, and pnpm deploy --prod carried typescript, ts-morph and Japa (~40 MB) into both production images.

The 12.8 fix from #15344 did not apply because the skip rule requires every importer that reaches the package to list the peer, and our workspace modules depend on @adonisjs/core without listing assembler.

Removal overrides (#15008) solved it at the source, one line per parent>peer:

overrides:
  '@adonisjs/core>@adonisjs/assembler': '-'
  '@adonisjs/auth>@japa/api-client': '-'
  # ... one per AdonisJS package that declares the peer

The prod closure dropped from 738 to 615 packages for one app and 673 to 524 for the other, with no tooling left. Dev kept working because core imports assembler via app.import() from the app root, and the Japa plugins resolve through the hoisted .pnpm/node_modules. A grep over the deployed .pnpm directory in the Dockerfile now fails the build if a tool ever ships again.