来了新共事，拉同一个我的项目到本地装置依赖之后跑不起来，然而其余三台电脑运行着都没问题。接下来就是逐渐定位问题，首先排除了代码问题，因为最新代码在其余共事不同零碎的电脑上都没失常运行，进过百度/谷歌/github issue搜寻报错、重复从新拉我的项目、重启电脑、重装环境、重装系统等一天的的操作之后，终于定位到大略是依赖包版本更新的问题。。

我的项目里一共有60+依赖，次要的几个依赖都是手动锁死版本的，但有个lozad没有锁死，而且前段时间应该是公布了次版本更新，跟nuxt的兼容有问题所以报了错。跟运行失常我的项目的node_moduels中lozad版本比照，改了之后果然我的项目就跑起来了。

npm包治理原理

在思考解决方案前，首先理解下npm包治理及依赖版本治理的原理。这些都是通过package.json文件实现的

当你应用npm装置一个包(并保留它)或者更新一个包的时候，package.json里就主动增加了一条信息，包含包名和其版本。npm默认装置最新版本，而后在其版本号之前增加一个^符号。比方^1.2.12，它表明最低应应用1.2.12版本。并且在这之上，领有雷同大版本号的任何版本都是OK的。毕竟小版本和bugfix版本不会对应用造成任何影响，所以用任何雷同大版本的更高级版本都很平安。

  • 符号^：示意主版本固定的状况下，可更新最新版。例如：vuex: "^3.1.3"，3.1.3及其以上的3.x.x都是满足的。
  • 符号~：示意次版本固定的状况下，可更新最新版。如：vuex: "~3.1.3"，3.1.3及其以上的3.1.x都是满足的。
  • 无符号：无符号示意固定版本号，例如：vuex: "3.1.3"，此时肯定是装置3.1.3版本。
举例："^1.2.3": 大于等于 1.2.3 且小于 2.0.0版本"^0.3.4": 大于等于 0.3.4 且小于 0.4.0版本"^0.0.6": 大于等于 0.0.6 且小于 0.0.7版本

版本依赖为什么须要锁定

没有版本锁定的状况下，在执行每次npm i的时候，对应的版本前都有个 ^ 符号。也就是未固定版本的依赖如果有了次版本更新或者订正版本更新，会主动装置对应的最新版。

在这种状况下，你再次install时装置的包的版本可能与前次不一样，具体的，你能够到package-lock.json中查看理论的包版本。

例如：A新建了一个我的项目，生成了下面这份package.json文件，但A装置依赖的工夫比拟早，此时packageA的最新版本是2.1.0，该版本与代码兼容，没有呈现bug。起初B克隆了A的我的项目，在装置依赖时packageA的最新版本是2.2.0，那么依据语义npm会去装置2.2.0的版本，但2.2.0版本的API可能产生了改变，导致代码呈现bug。

这就是package.json会带来的问题，同一份package.json在不同的工夫和环境下装置会产生不同的后果。

实践上这个问题是不应该呈现的，因为npm作为开源世界的一部分，也遵循一个公布准则：雷同大版本号下的新版本应该兼容旧版本。即2.1.0降级到2.2.0时API不应该发生变化。但很多开源库的开发者并没有严格遵守这个公布准则，导致了下面的这个问题。

为了在不同的环境下生成雷同的node_modules，引入版本依赖锁定就尤为必要了。

npm5.0之前能够通过npmshrinkwrap实现。通过运行 npm shrinkwrap，会在当前目录下生成一个 npm-shrinkwrap.json文件，外面蕴含了通过以后 node_modules 计算出的模块的依赖树及版本。只有目录下有 npm-shrinkwrap.json ，则运行 npm install 的时候会优先应用 npm-shrinkwrap.json 进行装置，没有则应用 package.json 进行装置。

在npm5.0之后,npm自带了package-lock.json文件，通过npm装置依赖，每当node_modules目录或者package.json发生变化时就会生成或者更新这个文件。不同版本有有些不同：

  • npm 5.0.x版本：不论package.json中依赖是否有更新，npm i都会依据package-lock.json下载。针对这种装置策略，有人提出了这个issue - #16866 ，而后就演变成了5.1.0版本后的规定。
  • 5.1.0版本后：当package.json中的依赖项有新版本时，npm install会忽视package-lock.json去下载新版本的依赖项并且更新package-lock.json。针对这种装置策略，又有人提出了一个issue - #17979，参考 npm 贡献者 iarna 的评论，得出5.4.2版本后的规定。
  • 5.4.2版本后：

如果只有一个package.json文件，运行npm i会依据它生成一个package-lock.json文件，这个文件相当于本次install的一个快照，它不仅记录了package.json指明的间接依赖的版本，也记录了间接依赖的版本。

如果package.json的semver-range version和package-lock.json中版本兼容(package-lock.json版本在package.json指定的版本范畴内)，即便此时package.json中有新的版本，执行npm i也还是会依据package-lock.json下载 - 实际场景1。

如果手动批改了package.json的version ranges，且和package-lock.json中版本不兼容，那么执行npm i时package-lock.json将会更新到兼容package.json的版本 - 实际场景2。

如果须要更新依赖依赖包版本，须要手动批改package.json中对应的版本或者指定依赖的版本号装置：npm i xxx@x.x.x。

更换/治理npm源

首先要说的是，很多同学可能习惯应用cnpm，因为装置速度的确比npm快不少，但在版本依赖锁定计划中，最根底的一条就是：不要应用cnpm，因为cnpm，是不反对依赖版本锁定的。也即是说，无论你的我的项目中有package-lock.json、npm-shrinkwrap.json还是yarn-lock.json文件，执行cnpm i装置依赖的时候他们都只是陈设，都只会依据package.json文件进行装置。所以通过cnpm装置依赖是不能防止下面问题的。而且有很多网友反馈cnpm会有依赖包失落的问题。

然而应用npm避不开的一个问题就是装置速度，切实太慢了。这里咱们能够通过手动更换npm源和nrm的形式实现应用npm命令的同时，仍然享受cnpm的装置速度。

手动更换npm源

设置npm源： npm config set registry [url]

查看确认: npm config get registry

应用nrm

装置nrm

npm i nrm -g

查看可选的源

nrm ls

其中，带*的是以后应用的源，下面的输入表明以后源是官网源。

切换到某个源:nrm use xx

例如切换到淘宝源：nrm use taobao

减少源（增加企业外部的公有源或者其余源）：nrm add [registryName] [url]

删除源：nrm del <registryName>

测试某个源的相应工夫：nrm test taobao

依赖版本锁定计划

大略有这么几条计划：

  1. package.json中固定版本
  2. npm+package-lock.json
  3. npm+npm-shrinkwrap.json
  4. yarn+yarn-lock.json

package.json中固定版本

最间接的，能够在package.json中写入固定版本号，也就是去掉版本号后面的~或者^，或者装置的时候加上--save-exact参数。但这样只能锁定最外一层的依赖，也就是这个依赖自身的其余依赖版本是不受管制的。所以不太举荐。

npm+package-lock.json

第一次npm i的时候会依据以后node_modules目录生成一个固定版本号的package-lock.json文件，前面如果装置新增的依赖，会自动更新这个文件。但如果须要更新以后某个依赖的版本号并锁定到package-lock.josn中，须要手动批改package.json中对应的版本或者指定依赖的版本号装置：npm i xxx@x.x.x。

npm+npm-shrinkwrap.json

这种形式锁定版本，每次依赖有新增或者版本更新之后，要手动智行npm shrinkwrap来生成或者更新版本锁定文件。

yarn+yarn-lock.json

yarn-lock.json与package-lock.josn原理相似，习惯用yarn命令的能够采取这种形式。

注：

如果我的项目中同时存在package-lock.json和npm-shrinkwrap.json,npm5 只会更新它，而不会生成 package-lock.json。

yarn 的锁定版本文件叫 yarn.lock，目前公布平台是反对的，不过最好保障我的项目中只有一个版本锁定文件，package-lock.json、npm-shrinkwrap.json 或者 yarn.lock 二选一，防止出现装置后果和料想不统一的状况。

npm和cnpm的区别

  • cnpm i不受package-lock.json影响，只会依据package.json进行下载。
  • cnpm i xxx@xxx不会更新到package-lock.json中去。
  • npm i xxx@xxx会跟新到package-lock.json中去
限时秒杀阿里云服务器ECS、云数据库MySQL、对象存储OSS等多种代金券

参考

npm shrinkwrap

那些年应用npm进行依赖管理所踩的坑

npm-shrinkwrap锁定依赖

npm5.0新增package-lock.json文件挖的坑

前端外围工具：yarn、npm、cnpm三者如何优雅的在一起应用 ？

npm的package.json和package-lock.json更新策略

Nrm装置与配置

应用 npm shrinkwrap 来治理我的项目依赖

npm的更新策略

npm ci 命令