fix: out-of-memory on peers resolution#8457
Conversation
|
Outside of memory usage, the previous behavior was better — would you agree @zkochan? The way pnpm ensures a peer dependency is respected through an entire dependency subgraph is one of my favorite features in pnpm because it allows incremental migration to a new major version of a dependency without accidentally leaking incompatible versions between those subgraphs. Would you be open to me trying to reduce the memory usage of the previous algorithm? I'm not sure if I'll succeed, but if so, would you be open to bringing the original behavior back in pnpm v10? |
|
I can definitively say that this would break a lot of things. My team very much depends on the strictness of nested dependencies getting their peer from the intervening version. Granted, we do our best to mitigate by using |
|
You can add a setting to return the previous behaviour, I guess. But I would love to see examples of projects where this change actually broke anything first. The change was tested on a wide range of big monorepos and looks like so far so good.
Right, but this change doesn't change anything in how peers are isolated in different projects of the workspace. So, you can still migrate projects in the workspace gradually.
If it does break something, please create an issue. We do try to resolve peers correctly but I feel like peers are overused by the ecosystem and as a result they stopped being singletons. This is a big problem and we need to find a way out from this peer dependency hell. Maybe by providing some more debug info or commands for analyzing peers. |
|
This appears to be an example of something that broke: |
This change could be considered disrupting but we don't have a choice, the current resolution algorithm causes out of memory errors without this change.
When a peer dependency is a prod dependency somewhere in the dependency graph, pnpm will not attempt to resolve the peers of that peer dependency differently in the subgraph.
For example, we have
react-domin the peer deps of theformandbuttonpackages.cardhasreact-domandreactas regular dependencies andcardis a dependency ofform.These are the direct dependencies of our example project:
These are the dependencies of card:
When resolving peers, pnpm will not re-resolve
react-domforcard, even thoughcardshadowsreact@16from the root withreact@17. So, all 3 packages (form,card, andbutton) will usereact-dom@16that uses react@16.formwill usereact@16, whilecardandbuttonwill usereact@17.Before this optimization
react-dom@16was duplicated for thecard, so thatcardandbuttonwould use areact-dom@16instance that usesreact@17.Before the change:
After the change
This might change the lockfile in some projects but I don't think it will break anything.