describe how npm 7 handles peer conflicts

[isaacs]

rfc

[ljharb]

It seems like it would be more ideal to, when a dep graph would have passed with --strictPeerDeps, ensure that future installs operate with strictPeerDeps. That way, an invalid dep graph can still be installed as users migrate to npm 7, but a valid dep graph can't suddenly become invalid without failing the install.

[ljharb]

so npm ls --legacy-peer-deps will have the flag as a noop, or will fail as an invalid flag?

[isaacs]

ls passes legacyPeerDeps: false in the arborist options regardless of what the config says.

[isaacs]

It seems like it would be more ideal to, when a dep graph would have passed with --strictPeerDeps, ensure that future installs operate with strictPeerDeps. That way, an invalid dep graph can still be installed as users migrate to npm 7, but a valid dep graph can't suddenly become invalid without failing the install.

This leaves you vulnerable to failing the install if a meta dep changes in such a way that the peer deps become invalid (but overrideably so).

Strict peer deps kind of has to be either the default always, or explicitly opt in, I think.

[ruyadorno]

this sounds a little bit confusing to me, so if z@1 is picked for the current level it means that z@2 gets duped under x ? (might be worth adding that bit here if that's the case, just for the sake of clarity for future readers)

[darcyclarke]

Action: update to show tree in both scenarios.

[ruyadorno]

would this "first peer dependency" happen to be the first one declared in the package.json file? Otherwise if there's no way at all to define it, it seem to me it might be better to just raise an error here too.

[isaacs]

It would be the first one encountered in a breadth-first traversal through the dependency graph, ordered alphabetically.

[Christian24]

As I had mentioned on the call:

• Where is the warning displayed? I guess the only warnings I only ever pay attention to is the audit output. So, maybe a summary below that would be nice?


• Are there plans to become more strict in the future? Maybe it might be useful to print a warning this "might break in future major versions of npm". This might enforce package authors to fix issues.

[isaacs]

@Christian24

Where is the warning displayed? I guess the only warnings I only ever pay attention to is the audit output. So, maybe a summary below that would be nice?


I agree, that would be nice. I'd rather keep this RFC more focused, and leave the position of warnings as a UI issue we can iterate on, since this is already quite long and dense. But I agree, printing it below any other install output would definitely be worthwhile. Since we're already doing some special treatment for ERESOLVE warnings (to turn the description object into a more human-readable form), it wouldn't be too hard to hold it and print below any other output. We can get that on a v7 patch release.

Are there plans to become more strict in the future? Maybe it might be useful to print a warning this "might break in future major versions of npm". This might enforce package authors to fix issues.

There's no plan to make --strict-peer-deps the default in the future, and it would have to be quite a long ways out in the future in any event, given the current state of peerDependencies usage in the registry today. I think it would not be a bad idea, but it would need another RFC, and some thorough investigation.

[ruyadorno]

Are there any tweaks from the actual implementation that landed in arborist needed to be added/changed here @isaacs or should we just land this?

[Anticom]

FYI: For the people looking for the RFC, it's here now.