一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第4天，点击查看活动详情。
瞎逼逼
最近在整公司的组件库。项目已经整完，在写博客记录自己所遇到的问题，写到 dependencies 和 devDependencies 发现他们我的印象十分的模糊，因为我开发中包放在 dependencies 和 devDependencies 他们好像没啥区别。 本地开发与线上都是可以运行, 因此具体不清楚他们的区别，所以就看到几篇文章，但是也是讲的不清晰，看到知乎的讨论不错: dependencies与devDependencies貌似一点区别都没有，姿势不对还是理解有误？？。
推荐看官网:
开始说他们的区别
其实在项目开发你如果不发布npm包的话，这两个没啥区别，都会把你需要安装都放到node_modules下面。但是如果这个项目你是发布到npm的包就有区别了。
这里假设 B是 npm包， A是 项目
当A 使用 B 时 会 npm install B 下载了B, 当安装B时 也会安装B dependencies 下面的包。 这个时候如果B dependencies下的包有些是打包工具例如 rollup 。 但是 A项目使用 webpack 打包不需要rollup，那么这就额外增加了 A 的install rollup。 当然 A 项目安装 B 放在 dependencies 还是 devDependencies 都是没啥区别的，但是最好还是规范化下。
规范化:
-
当这个包只是开发时使用，线上运行时就不用，应放在 devDependencies 如：
babel-core、babel-eslint、等babel系列，autoprefixer、webpack、webpack-dev-server、*-loaderloader系列等等 -
当这个包开发时使用并且线上运行时也使用，应放在 dependencies 如：
react、vue、react-redux、react-router-dom等
衍生
当 A 的 node_modules 已经存在 B dependencies 的包，还会重洗下载安装嘛？
例子: A node_modules/core-js 的版本为 3.6.1， B dependencies 的 core-js 为 3.22.1。
会重新安装，但是安装的core-js: 3.22.1 是放在 node_modules/B/node_modules，目录结构如下
｜- A
｜- node_modules
｜- B
｜- node_modules
｜- core-js 3.22.1
｜- core-js 3.6.1
如何减少 core-js 的多次安装
这里就导致了重复性的安装 core-js 。 因此我们可以把 core-js 放到 peerDependencies 就不会再安装了。
# 原先 B 的 package.json
dependencies {
"core-js": "^3.22.0",
}
更改
# 原先 B 的 package.json
peerDependencies {
"core-js": "^3.22.0",
}
当 A npm install B 只安装 B 不会在 B 的下面装 core-js: "^3.22.0
需要自己去安装 core-js 了。但是可能就会出现版本错误问题。因为 A 使用的 core-js: 3.6.1 版本比 B要用的低。A 的 core-js 需要升级。
npm install 存在的问题
其实下面问题是根据这篇文章: npm与yarn对peerDependencies处理的差异
这篇文章讲到了npm 的 hoist 问题。例如把上面core-js 变成 less-loader 与 less
# B 的 package.json
dependencies {
"less": "^4.1.2",
"less-loader": "^10.2.0"
}
当 A 本地安装了一个less: 3.0.0用于之前的使用。 这个时候你去安npm install B 目录结构就发现了变化。
｜- A
｜- node_modules
｜- B
｜- node_modules
｜- less 4.1.2
｜- less 3.0.0
｜- less-loader
这个时候就发现less-loader 需要的less 版本就会对应不上。 less-loader 需要 3.5.0 或者 4.0.0 之上的。3.0.0肯定不满足。
这个时候就使用 yarn add B
｜- A
｜- node_modules
｜- B
｜- node_modules
｜- less 4.1.2
｜- less-loader
｜- less 3.0.0
当然那篇文章下面有人评论 yarn 的 hoist 也是不太稳定。建议使用 pnpm 这个我也没有用过，但是最近看到pnpm 次数有些多，当我有时间了去了解下，再把这块这里更新下。
版本号前面的符号啥意思
version
必须匹配某个版本
如: 2.2.1, 表示必须依赖2.2.1版的依赖包
>version
必须大于某个版本
如: >2.2.1, 表示必须依赖大于 >2.2.1版的依赖包
>=version
必须大于或等于某个版本
如: >=2.2.1, 表示必须依赖大于或等于 >=2.2.1版的依赖包
<version
必须小于某个版本
如: <2.2.1, 表示必须依赖小于 <2.2.1版的依赖包
<=version
必须小于或等于某个版本
如: >=2.2.1, 表示必须依赖小于或等于 >=2.2.1版的依赖包
~version
不改变大版本号和次要版本号,小版本号随意
注意:
如果按照版本号格式,X.Y.Z,那么小版本号就是随意
如: ~2.2.1, 表示 >=2.2.1 <2.3.0 版的依赖包 (可以是2.2.1, 2.2.2, 2.2.3, …, 2.2.n)
如果版本号格式,X.Y,那么跟正规格式的意义相同
如果版本号格式,X,那么次要版本号和小版本号可以随意
如: ~2, 表示 >=2.0.0 < 3.0.0版的依赖包 (可以是2.0.0, 2.0.n, 2.1.0, …, 2.n.n)
^version
版本号最左边非 0 数字的右侧可以任意
如: ^2.2.1,表示 >=2.2.1 < 3.0.0版依赖包
^0.2.1,表示 >=0.2.1 <0.3.0版依赖包
^0.0,表示 >=0.0.0 <0.1.0版依赖包
version号位置出现 X
X 的位置表示任意版本
如: 2.2.x,表示 >=2.2.0 <2.3.0版依赖包
version使用 * 代替
任意版本, *""*也表示任意版本
如: *, 表示 >=0.0.0版依赖包
version(1) - version(2)
大于等于version(1),小于等于version(2)
如: 2.2.1 - 2.3.1, 表示 >=2.2.1 <=2.3.1版依赖包
根据前面十条设置版本号规则,range(1)||range(2)
满足range(1)或者满足range(2),可以设置多个范围,用空格隔开
如: <2.2.1||>=2.3.1 <2.4.1||>2.5.1 <2.6.1,表示三个范围的版本号都可以
上面复制张贴来的复制的文章: npm依赖包版本前面符号的意义
还有写功能,自己看吧.
versionMust matchversionexactly>versionMust be greater thanversion>=versionetc<version<=version~version"Approximately equivalent to version" See semver^version"Compatible with version" See semver1.2.x1.2.0, 1.2.1, etc., but not 1.3.0http://...See 'URLs as Dependencies' below*Matches any version""(just an empty string) Same as*version1 - version2Same as>=version1 <=version2.range1 || range2Passes if either range1 or range2 are satisfied.git...See 'Git URLs as Dependencies' belowuser/repoSee 'GitHub URLs' belowtagA specific version tagged and published astagSeenpm dist-tagpath/path/pathSee Local Paths below
参考: dependencies
参考文章
dependencies与devDependencies貌似一点区别都没有，姿势不对还是理解有误？？
