「shrinkwrap」npm-shrinkwrap锁定依赖

shrinkwrap

写在前面

npm采用语义化的版本号 semver 进行控制，让开发过程中依赖的获取和升级变得非常容易，但不严格的版本号控制，也带来了不确定性~~

npm 建议使用semver版本，部分包不遵循semver；

package.json 可以使用精确的版本号控制你的直接依赖包，但第三方依赖的包无法管理；

在开发阶段执行得到的版本，和后续部署时得到的可能是不一致的，更不可控的是，你依赖的第三方包也有这样的情况会导致潜在的上线风险。

目前主流的版本控制使用的是 semver 语义化版本。即，X.Y.Z （主版本号.次版本号.修订号）

主版本号：当你做了不兼容的 API 修改
次版本号：当你做了向下兼容的功能性新增
修订号：当你做了向下兼容的问题修正

也可以将先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。(v1.2.2-beta)

# 查看当前哪些包需要更新
$ npm outdated -g -depth=0

Package	Current	Wanted	Latest
webpack	4.6.0	4.17.1	4.17.1
pm2	2.6.1	2.10.4	3.0.4
commitizen	2.9.6	2.10.1	2.10.1

安装依赖

npm install 会生成 package.json，以及 node_modules (依赖树)。

同一套 package.json 生成相同的 node_modules 吗？实际情况并非如此！

不同的npm版本，安装算法可能存在差异；
依赖包发布了新 semver-range 版本；
某个依赖项的依赖发布了新版本，且其使用 ^1.2.3 方式，即使你的项目中制定了固定版本；
安装的版本不在可用，或出现版本变异。

锁定依赖

默认情况下，当用 --save/-S 或者 --save-dev/-D 安装一个模块时，npm 通过脱字符(^)来限定所安装模块的主版本号。

方式一：prefix控制

符号	当运行 `npm update` 时，情况说明	备注
`^1.5.1`	【限制主版本号】允许安装版本号大于 `1.5.1` 但小于 `2.0.0` 版本的模块	默认
`~1.5.1`	【限制次要版本】允许安装版本号大于 `1.5.1` 但小于 `1.6.0` 版本的模块	`npm config set save-prefix="~"`
`1.5.1`	【精确控制】允许安装版本号大于 `1.5.1`	`npm config set save-exact true`

所以，我们可以将需要安装的模块版本前缀默认设置成波浪号(~)；对于那些偏执的认为任何更新(模块的行为)会破坏系统的人，可以配置npm仅安装精确版本号的模块。

方式二：shrinkwrap

另一个选择是，可以在项目中使用 shrinkwrap，在开发阶段依赖稳定后，运行如下命令：

npm shrinkwrap
npm shrinkwrap--dev # 将dev-dependencies计算在内

这会生成一个 shrinkwrap.json 文件，该文件包含了你正在使用的模块的指定版本。当运行 npm install时，该文件所指定的模块版本会覆盖 package.json 文件中所指定的版本。

注意问题：

shrinkwrap计算时是根据当前依赖安装的目录结构生成的，如果你不能保证package.json文件定义的依赖与node_modules下已安装的依赖是匹配、无冗余的，建议在执行shrinkwrap命令前清理依赖并重新安装（rm -rf node_modules && npm install）或精简依赖（npm prune）。
默认情况下，shrinkwrap只计算dependencies依赖，而不计算dev-dependencies，如果在生产环境也需要开发依赖或你的依赖分类不清晰，使用--dev参数生成shrinkwrap文件确保不会出问题。

增加、更新、删除包的步骤如下：
第一步： 安装指定版本包 npm install/uninstall package_name@version --save ；
第二步： 测试功能，功能正常后，执行 npm shrinkwrap 把依赖写入 shrinkwrap 文件；
第三步： 在代码库中提交 shrinkwrap / package.json 描述。

版本控制

package-lock.json

对于 node_modules 或 package.json 的任何修改，都会自动生成 package-lock.json。它描述了生成的确切树，以便后续安装能够生成相同的树，而不管中间依赖性更新。

`shrinkwrap.json`

为防止出现这种潜在问题，npm使用 package-lock.json 或 npm-shrinkwrap.json（如果存在）。这些文件称为包锁或锁文件。

{
  "name": "A",
  "version": "0.1.0",
  ...metadata fields...
  "dependencies": {
    "B": {
      "version": "0.0.1",
      "resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz",
      "integrity": "sha512-DeAdb33F+"
      "dependencies": {
        "C": {
          "version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
        }
      }
    }
  }
}

该文件描述了一个精确的、可重现的 node_modules 树。一旦它出现，任何未来的安装将基于此文件的工作，而不是从 package.json 重新计算依赖版本。此外，如果 package-lock.json 和 npm-shrinkwrap.json 都存在于包根目录中，则将忽略 package-lock.json 。

npm install，npm rm，npm update 等都将自动同步现有的锁文件。为了防止发生这种更新，你可以使用--no-save 选项来防止完全保存，或者 --no-shrinkwrap 允许更新 package.json 保留 package-lock.json 或npm-shrinkwrap.json 。

注意：强烈建议库作者不要发布此文件，因为这会阻止最终用户控制传递依赖性更新。

问题补充

npm@5、npm@6 版本对于 requires 机制差异！（下图左侧npm@5，右侧npm@6）

在这里插入图片描述

是由于官方对其处理方式做了变更：

相关社区讨论：https://npm.community/t/package-lock-json-contains-dynamic-version/6080/9

相关ChangeLog说明：https://github.com/npm/cli/blob/latest/CHANGELOG.md#new-features-7

npm-shrinkwrap锁定依赖