共计 4195 个字符，预计需要花费 11 分钟才能阅读完成。
npm 是 Node.js 规范的软件包管理器，本文将针对 npm 机制进行浅谈，并比照 npm 与 cnpm、yarn 的区别。
如何装置单个 npm 包
dependencies 和 devDependencies 的区别在一般的前端我的项目中体现不显著。
在一般的前端我的项目，如 vue 框架中，这两者次要是明确在我的项目代码中，实际上用到了哪些依赖包。
而只有装置两者，程序能力跑起来（因为 devDependencies 个别会蕴含程序的运行环境依赖）。
在纯 node 我的项目中则不同，上面能够看一个 node 我的项目的依赖配置。
这个 node 我的项目，只装置 dependencies 就能够运行我的项目了（通过 NODE_ENV=production npm i）。而装置了 devDependencies 后，就会让编辑器的 eslint 检测插件开始工作，或者是能够用 jest 进行单元测试。
这个是真正意义上的开发环境与生产环境拆散。
npm install 默认会装置依赖包的 dependencies 字段和 devDependencies 字段中的所有模块。
NODE_ENV=production npm i 时，只会装置依赖包中的 dependencies 模块。
开发某些第三包时，须要关注这一点，把我的项目运行所依赖的包都放在
dependencies中。也不要把一些乌七八糟的包都放进去，这样你的包会变得很大。
如何应用或执行 npm 装置的软件包
比方 eslint，全局执行的话，会生成一个全局命令。
然而，有些命令包我只想在某个我的项目中装置应用，怎么做。
加上 npx 即可，例如 npx eslint，npx 首先会寻找我的项目中曾经装置的包，再寻找全局装置的包，如果都没有找到的话，npx 会先装置这个包，而后再执行命令。
package.json 和 package-lock.json
版本零碎与 package.json
npm 遵循语义版本控制规范。
- 什么是语义版本控制规范？
简略地说：
1.5.4 是版本号，其中
- 1 是主版本号，代表的是不兼容的 API 批改
- 5 是次版本号，代表的是向下兼容的功能性新增
- 4 是订正号，代表的是向下兼容的问题修改
案例 1：
如果在 1.0.0 中，提供了 main.any 办法，而在新版本中删除了这个办法，那么你应该公布 2.0.0 版本。
如果一个包常常公布原先版本不兼容的大版本，那么这个库应该反思一下，不然的话预计很快就会凉凉。
案例 2：
如果在 1.0.0 中，提供了 main.any 办法，而在新版本中新增了 main 办法，成果与 main.any 一样，那么你应该公布 1.1.0 版本，main 属于次版本中新增的办法。
案例 3：
如果在 1.0.0 中，提供了 main.any 办法，在新版本中修复了该办法的局部场景下的 bug，并且确保单元测试曾经笼罩所有场景，那么你应该公布 1.0.1 版本，修复该问题。
如果你不确定批改此 bug 后，是否会引发局部场景的行为不统一，那么你应该公布 1.1.0，局部没有遇到原场景 bug 并且只更新订正版本号的用户就能够避开这个问题。
- 在
package.json中，如何配置第三方包的版本？
Semver 标准：
- 如果写入的是 〜0.13.0，则只更新补丁版本：即 0.13.1 能够，但 0.14.0 不能够。
- 如果写入的是 ^0.13.0，则要更新补丁版本和次版本：即 0.13.1、0.14.0、依此类推。
- 如果写入的是 0.13.0，则始终应用确切的版本。
- 还有更多规定，比方：
>、>=、||，不过也应该不怎么罕用，就不开展介绍了。
以 vue 脚手架为例，生成的我的项目依赖是这样的：
能够看出，脚手架相干的库都应用了只更新补丁的模式；而其余的包都抉择更新次版本号的性能，从而引入一些向下兼容的最新个性或是优化性能。
因而，只通过 package.json 的话，原始的我的项目和新初始化的我的项目（很大概率）实际上是不同的。
即便是补丁版本或次版本不应该引入重大的更改，但还是可能引入缺点（你没法确定你应用的每一个第三方包的更新具体干了什么）。
锁定版本与 package-lock.json
npm@5 版本后，推出了 package-lock.json 机制。
package-lock.json 会固化以后装置的每个软件包的版本，当运行 npm install 时，npm 会应用这些确切的版本。
以 vue 举例，在 package.json 中是 ^2.6.11 版本，而在理论装置过程中，装置了 2.6.14 版本，并且在 package-lock.json 文件中，将版本锁定在了 2.6.14。
在 package-lock.json 锁定版本后，将此文件留在 git 仓库中，就能够保障原始的我的项目和新初始化的我的项目装置的依赖是统一的。
如果想要更新 package-lock 中锁定的版本，则应用 npm update 命令（此命令不会更新主版本），能够在遵循 semver 规范的前提下，更新依赖包，并且更新 package-lock 锁定的版本到最新版本（仍旧锁定）。
为啥 package-lock.json 文件比 package.json 包大那么多？
因为 package-lock.json 不仅锁定了我的项目中的依赖包，还把依赖包的依赖都用套娃的形式锁住了，所以整个文件会十分大。
这里会引发另一个问题，那就是 npm update 时，会把依赖包的依赖都降级。对于一个稳固运行很久的我的项目来说，危险还是比拟大的，倡议还是降级某个特定的包（npm i xx@version）。
有了
package-lock.json后，package.json的版本更新规定就不失效了，会优先读取package-lock.json中锁定的包版本进行装置，保障你的代码库能顺利运行，不会因为依赖包频繁更新而频繁引发问题。
想晓得本人的包离最新的包差几个版本的话，输出 npm outdated 命令：
Latest 是这个包的最新大版本，Wanted 是这个包以后大版本下的最新小版本。
想晓得理论装置的包版本
- 笨办法：去
node_modules外面找。 - 聪慧一点：去
package-lock.json外面找，因为外面曾经锁了理论装置的版本。 - 用
npm list --depth=0看整个我的项目的依赖包版本。 npm view [package_name] version
在理论应用中，3 和 4 的命令不常常用的话，容易遗记。我之前比拟罕用的是第一种笨办法，当前会用第二种办法，显著不便地多。
yarn 和 npm
- 依赖版本
晚期的时候 yarn 有 yarn.lock 来锁定版本，这一点上比 package.json 要强很多，而前面 npm 也推出了 package-lock.json，所以这一点上曾经没太多差别了。
- 装置速度
yarn 感觉要比 npm 快很多，这是因为 yarn 采纳并行装置依赖的形式，而 npm 是串行。
在缓存机制上，目前差异性并不是很大，都会读取本地缓存。
- 用哪个？
目前 2021 年，yarn 的装置速度还是比 npm 快，其余中央的差别并不大，基本上能够疏忽，用哪个都行。
装置依赖太快了也不肯定就好，有时候，装置速度慢一点，还能喝杯茶点根烟，劳动一下。
在设计上，
yarn的输出会比npm更合乎人体工学一点。然而以公司的网络状况来看，很多人都会用
cnpm。
cnpm 和 npm
- cnpm 比 npm 快多了
因为 cnpm 的镜像仓库在国内（淘宝机房），比 npm 当然快多了。不过当初 npm 加了缓存机制，速度也跟上来了。（除了 node-sass 这个玩意）
而还有局部依赖包，外部就调用了 npm install，所以 … 还是慢。
你也能够将
npm的镜像源设置为淘宝镜像，这样也会快上不少。
npm config set registry http://registry.npm.taobao.org
- cnpm 没有 package-lock.json
这可能是个很坑的中央，cnpm 装置时不会产生 package-lock.json，并且我的项目中即便有 package-lock.json，cnpm 也是不管不顾的，只读取 package.json。
这个机制可能就会导致你代码中的依赖库须要在 package.json 中就锁住，不然的话 … 在某一天，cnpm 就可能会把你坑了。
这预计是应用 cnpm 最大的隐患。
- 对于第二点，作者的回应
对于这一点，cnpm 作者的回应是，当初不反对，当前也不思考反对。
作者提到，如果锁了版本，很多暗藏的 bug 可能很难被修复，可能会成为某个 bug 的受害者。
对于依赖版本可能多个环境不统一，作者给出的回答是对整条运维公布体系进行调整，比方在多个环境 cnpm 验证后，再公布到生产。（对于作者的这个计划，我感觉不太靠谱，次要是老本和收益不成正比，不是每一个前端都有这么大的能量的）
作者又说，如果真的有 bug 没修复，就间接回滚版本，缩小故障影响范畴。（…）
很多人都不太认同作者的观点，认为锁版本的危险会小很多。
这里其实还存在一个隐患，就是你用的包不肯定遵循 Semver 标准，他可能发个补丁版本，间接来了个大改，或者基本没有单元测试（特地是你在用一些比拟冷门的包的时候）。
即便是比拟有名的包，举个栗子，圣诞彩蛋事件：
在 antd 包中，其中 3.9.3、3.10.0 ~ 3.10.9、3.11.0 ~ 3.11.5 版本中蕴含了一个圣诞彩蛋。
在圣诞节的那天，所有的 Button 组件都被加上了雪花。
如果在过后，你锁了版本，那么你就有肯定概率避开这个问题。
如果你没有锁版本，那么你很大概率会中招。
- 有些依赖包用不了
有些依赖包用 cnpm 装置就不能用，用 npm 装置就能够用，这个问题预计和 cnpm 包的应用软链接的形式有关系（并不确定）。
cnpm 和 npm 混用，导致包挂了，这个能够确定是 cnpm 应用软链接的问题。所以，还是尽量不要混用吧。
- 总结
能用 npm 最好用 npm，公司外部的 公有镜像源 也倡议做成 npm，毕竟 cnpm 还是存在一些隐患。
pnpm 和 npm
看很多人安利，特点就是快。
我感觉这个快不快的在平时开发过程中曾经算不上长处了，也不差这点工夫。
在生产容器内装置依赖时能够考虑一下。
总结
当初 npm 也挺好用的了，最好还是用 npm。
如果在装置速度上有问题的话，能够搭建一个公有 npm 镜像源，将一些装置过的包都存在镜像源上。
最初一件事
如果您曾经看到这里了，心愿您还是点个赞再走吧~
您的点赞是对作者的最大激励，也能够让更多人看到本篇文章！
如果感觉本文对您有帮忙，请帮忙在 github 上点亮 star 激励一下吧！