Motivation ("The Why")

The semantic is not well defined yet for the case when the same package is specified both as a peer dependency and a regular dependency, at least I have not been able to find a clear definition what should happen in this situation. It would be great if peer dependency had a priority over regular dependency in this case with fallback to a regular dependency if parent had not satisfied peer dependency.

Example

package.json:

{
  "name": "example",
  "version": "1.0.0",
  "dependencies": {
    "bar": "file:./bar",
    "left-pad": "1.1.0"
  }
}

bar/package.json:

{
  "name": "bar",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "^1.3.0"
  },
  "peerDependencies": {
    "left-pad": ">= 1.0.0"
  }
}

How

Current Behaviour

Currently npm ignores peerDependencies definition and treats foo as a regular dependency. This results in node_modules/[email protected] and bar/node_modules/[email protected] to be installed.

Desired Behaviour

It would be great if npm gave priority to peerDependencies in the situation when the dependency is both a peer and a regular dependency.

This would have resulted only in one version of node_moduules/[email protected] being installed and used both by example and by bar packages in the example above.

It would also lead to a semantically correct way to define singleton packages in the whole dependency graph of a project, by listing singleton packages as both dependencies and peerDependencies without a need from a user to make a decision how to satisfy these peerDependencies. It will also gave the user a mechanism to override the version of the singleton for the whole dependency graph by providing a version for such a dependency in the root package.json.

References

• n/a