Suppose we have two npm modules A and B, A is B's plugin.
If ABAP's package.json defines B as its dependency:
{
"dependencies": {
"B": "1.2.0"
}
}
Then after we install A in the host application, the hierarchical result is as follows:
node_modules
|_ A
|_ node_modules
|_ B
Assuming we install two more modules C and D, the node_modules folder becomes the following structure:
node_modules
|_ A
| |_ node_modules
| |_ B
|_C
| |_ node_modules
| |_ B
|_D
|_ node_modules
|_ B
This will work if the installed B versions are all the same, but if not we run into potential problems. Of course we're also ignoring the fact that we're actually duplicating module B three times, which is pointless.
The point here is that if a developer declares B as a peer dependency of A, C, and D, our package manager of choice will do one of two things. It either just ignores this dependency (as Yarn does by default) and leaves it to the developer to make the decision.
or like npm:
- Check if B is already installed
- If yes, end the current detection and proceed to the next packet processing and ignore it
- If not, the package manager will try to install B correctly at the root level (ie in project/node_module). If the installation fails, it will abort with the corresponding error message
One of the reasons a peer dependency cannot be installed successfully is because of conflicting versions. For example, A depends on version 2.0.0 of B, and C depends on version 7.1.3 of B. If B uses semver (semantic versioning) correctly, there will be many breaking changes between the two versions, so A may not work with the version required by C, and vice versa. In this case, developers need to make their own choices.
Peer-to-peer dependencies really come into play when we are developing code that will be reused by other consumers, such as plugins and packages. If you are only developing final product-level applications, you do not need to consider Peer Dependency.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。