npm shrinkwrap 是 npm 包管理器的一项功能。可以按照当前项目 node_modules 目录内的安装包情况生成稳定的版本号描述。shrinkwrap 文件的结构类似以下这种形式:
{
"name": "A",
"version": "1.1.0",
"dependencies": {
"B": {
"version": "1.0.1",
"from": "B@^1.0.0",
"resolved": "https://registry.npmjs.org/B/-/B-1.0.1.tgz",
"dependencies": {
"C": {
"version": "1.0.1",
"from": "org/C#v1.0.1",
"resolved": "git://github.com/org/C.git#v1.0.1"
}
}
}
}
}
重要的字段一个是 version
(模块的版本),以及 resolved
(模块的安装路径)。在工程中有 shrinkwrap 描述文件的情况下会遵循该 version 和 resolved 信息去安装。
在没有 shrinkwrap 的项目中,任意一个依赖包都可能在开发者不知情的情况下发生改动,进而引发线上故障。
在一个 JavaScript 项目中,每次执行 npm install
,最后生成的结果可能是不一样的。 譬如说现在某个项目依赖了模块 A, 虽然我们可以为它指定一个固定的版本号,然而 A 所依赖的其它模块版本使用的是 npm semver 规则(semantic version,npm 模块依赖默认遵循的规则)。它并不严格规定版本,而是选择符合当前 semver 规则的最新版本进行安装。
一个简单的例子:假如模块 A 中依赖了 B,并且在 A 的 package.json 中指定 B 的 semver 为 ~1.2.3,那么所有形式为 1.2.x 的版本都是符合规则的。当模块 B 更新了一个 1.2.x 的小版本后,项目在下次构建中就会获取到它。
semver 这样设计的初衷是使模块的开发者可以将 bugfix 等微小的改动能更便捷地到达使用方。但它的负面影响却是使每次 npm install 构建过程之间,项目内的模块内容随时可能发生改变。我们没法确定在每个模块内部,每一次小版本更新时究竟是加入了 bugfix,还是改变了 API,亦或是注入了恶意代码。
为了保证线上构建的稳定性,我们决定强制在每个 JavaScript 项目中添加 shrinkwrap。
npm shrinkwrap
命令来生成一个。第一次生成时经常会遇到错误,请看下面的 trouble-shooting 部分。就是以上这些,项目中有了 npm-shrinkwrap.json 以后,每次执行 npm 模块安装的时候就会首先遵循 npm-shrinkwrap.json 的版本来安装
大多数时候是由于 shrinkwrap 中含有官方源的包。请检查你的 npm-shrinkwrap.json,里面如果含有 https://registry.npmjs.org
,代表你的相关模块将会从官方源装(速度极慢),请将它们批量替换为 https://repo.corp.qunar.com/artifactory/api/npm/npm-qunar
,使其改为从内网源安装。
大多数错误有一个公用的解决方案——升级到 npm5,如果你执意不升级的话请往下看。
生成 npm-shrinkwrap.json
过程的中报错,大多是因为 package.json 和 node_modules 中对于模块的描述不一致(其实是不应该出现的),按照提示的信息改正即可。下面列两个最常见的错误。
代表这个
解决方法:如果你需要这个包,请添加到 package.json 中。如果你不需要它,从 node_modules 中删除即可。
代表这个
解决方法:安装一个你需要的版本保证两边的统一。
另外 ykit 在 qunar 插件中也提供了 shrinkwrap 功能,比 npm 本身的规则更宽容,当然最好的办法还是升级 npm5。
npm5 本身有一个锁定版本号的文件 package-lock.json,但是目前发布平台还不支持。如果项目中有 npm-shrinkwrap.json,npm5 只会更新它,而不会生成 package-lock.json,所以不用担心。
yarn 的锁定版本文件叫 yarn.lock,目前发布平台是支持的,不过最好保证项目中只有一个版本锁定文件,npm-shrinkwrap.json 或者 yarn.lock 二选一,防止出现安装结果和预想不一致的情况。
如果还有问题请 qtalk 联系 siven.jin
。