In the post npm@3 world:
peerDependencies are assertions that result in warnings if they fail. So a pretty soft assertion. They instruct folks to install the missing peer dep, but make no attempt to install it themselves.
There is one lingering issue relating to them, as this assertion framework is a little brittle: If your applciation depends on library A which depends in turn depends on B and C. And C has a peer dep on B. It’s possible for B to get installed under A, but C installed at top level, resulting in an unresolved peer dep when it otherwise should be resolved.
I have some thoughts on how we can address this, but it will require some deep changes to how we resolve module trees and so is scheduled for post npm@7 (so, end of this year, probably).
In the meantime, authors of module A can ensure this doesn’t happen by shipping an
npm-shrinkwrap.json or by bundling B and C.