【前端随笔】package.json的dependencies : "0.0.1"

区分一下三个dependencies：dependencies、dev-dependencies、peer-dependencies，主要记录peer-dependencies

 

这里以项目project、将要引入的npm包package、以及package里的依赖A切入：

 

开发好的npm包package的依赖默认会记录在dependencies里，当项目project引入这个包，启动项目前install安装依赖和子依赖的依赖时，project里的依赖A会被安装，这里会有多种情况：

1. project没有package的依赖A，就会在项目project的node_modules里安装A（扁平化处理）；

2.如果项目project里已经包含这个依赖A，就会将项目的依赖A和package的依赖A进行版本比较，package的依赖A的版本号不符合匹配规则（规则取决于符号“^”、"~"等），则会在项目project的package组件包下生成新的node_modules文件夹，并安装A；

 

如果开发的package包将依赖A记录在dev-dependencies中，项目project引入package时，就不会去安装package依赖的A；

 

如果依赖A是记录在peer-dependencies中，项目project引入package时，

1. project没有package的依赖A，就会在项目project的node_modules里安装A（扁平化处理）；

2.如果项目project里已经包含这个依赖A，npm6会以project的依赖A为主，即不会再在package中生成node_modules文件夹安装依赖A，而npm7会抛出异常并提供了两种解决方法：legacy-peer-deps和force：

• --legacy-peer-deps：安装的时候忽略所有对等依赖（peerDependencies），以 npm v4 ~ v6 的方式安装
• --force 或 -f： 强制安装

执行legacy-peer-deps意味着依赖A的版本以宿主环境（project）的依赖为主；

执行force则会在project中强制安装package中依赖A的版本号；

 

总结：当包的依赖记录于dependencies时，项目project直接install确实省事，但是也可能会没必要的安装依赖（虽然依赖包版本号前带有^或者～，但它们只能解决小版本的差异，可能存在情况：大版本的差异并非必须安装），这时就用到peer-dependencies，但它可能带来的问题：项目跑不起来了。所以，npm包的依赖和项目的依赖发生大版本差异时，既想避免没必要的依赖安装，又想项目功能正常，仍然是取决于依赖自身的版本兼容性。

 

最后，复制粘贴下大神对这3个dependencies的定义：

dependencies 表示生产依赖，在此选项中定义的依赖都是需要在生产环境上运行的。当它作为一个 npm 包中的依赖声明被引用下载时，在此选项中定义的依赖都会被下载，如果在依赖树中已经存在相关依赖了，那么就需要进行依赖版本的判断，如果符合那么就会被丢弃，不符合那么就会在该模块下的 node_modules 中新建一个依赖项。

devDependencies 表示开发依赖，在此选项中定义的依赖都是不需要在生产环境上运行的，一般只在开发阶段起作用或者只在开发环境中被用到。当它作为一个 npm 包中的依赖声明被引用下载时，在此选项中定义的依赖都不会被下载。

peerDependencies 表示同版本依赖，简单来说就是，如果你安装我，那么你最好也安装我对应的依赖。比如你安装 Element Plus，那么你也需要安装 Element Plus 的 peer 依赖，因为 Element Plus 脱离了 peer 依赖是无法单独运行的，它必须宿主环境提供对应的 peer 依赖。

参考文章：https://juejin.cn/post/7170716245762048036#heading-8