使用 npm shrinkwrap 来管理项目依赖
管理依赖是一个复杂软件开发过程中必定会遇到的问题。 在Node.js项目开发的时候,我们也经常需要安装和升级对应的依赖。虽然 npm 以及语意化的版本号 (semantic versioning,semver) 让开发过程中依赖的获取和升级变得非常容易, 但不严格的版本号限制,也带来了版本号的不确定性。主要的问题可能有三个:
如果要控制上线的风险,我们就必需要解决这个问题,这时候,就需要使用 介绍 shrinkwrap 比方说,有一个包 A {
"name": "A","version": "0.1.0","dependencies": {
"B": "<0.1.0"
}
}
还有一个包 B "B",0)">"0.0.1","dependencies": {
"C": "<0.1.0"
}
}
以及包 C "C",0)">"0.0.1" } 你的项目只依赖于 A,于是 A@0.1.0
`-- B@0.0.1 `-- C@0.0.1
这时候,B@0.0.2 发布了,这时候在一个新的环境下执行 `-- B@0.0.2 `-- C@0.1
这时候两次安装得到的版本号就不一致了。而通过 shrinkwrap 命令,我们可以保证在所有环境下安装得到稳定的结果。 在项目引入新包的时候,或者 A 的开发者执行一下 这个文件内容如下
{
"name": "dependencies": {
"B": {
"version": "dependencies": {
"C": {
"version": "0.0.1"
}
}
}
}
}
shrinkwrap 命令根据目前安装在node_modules的文件情况锁定依赖版本。在项目中执行 这样一来,在安装时候确定的所有版本信息会稳定的固化在 shrinkwrap 里。无论是A,B 和 C中的版本如何变化,或者它们的 package.json 文件如何修改,你始终能保证,在你项目中执行 在开发中使用 shrinkwrap在开发过程中,引入一个新包的流程如下
升级一个包的流程应该是这样
删除一个包的流程如下
比一般的安装多了一步手工生成 shrinkwrap 文件。在实际工作中,有时候我们会忘记这一步,导致上线时候没有获取到依赖包的特定版本。 介绍 npm-shrinkwrap-install去年我引入 shrinkwrap 工作流的时候,npm 官方的 shrinkwrap 命令还有很多问题,比如
所以我写了一个bin/shrinkwrap 脚本。这个脚本会自动对比 package.json 和 npm-shrinkwrap.json 文件的区别,获取需要更新的版本,然后对相关信息进行更新。(更新:现在的 npm shrinkwrap 已经修复了很多的问题,但 from 字段有时候仍然有些小问题。) 当时为了忽略 devDependencies 和 optionalDependencies,我会执行 后面 uber 发布了npm-shrinkwrap 工具,可以更高效的生成版本描述。可惜这个包不支持 scoped package。我花了一点时间 patch 了这个工具,因为它们的发版太慢,所以我发布了一份@th507/npm-shrinkwrap,可以支持 scoped package。 在上面这个包的基础上,我还写了另外一个小工具,叫做npm-shrinkwrap-install,它可以无缝替换 安装$ npm install npm-shrinkwrap-install
安装完成之后,有如下命令可以使用 安装依赖的命令 npm-install npm-i 删除依赖的命令 npm-unisntall npm-un npm-remove npm-rm npm-r 手工生成 shrinkwrap 描述 npm-shrinkwrap 在开发中使用 npm-install引入新依赖包
npm-install 在运行时会对 package.json 中的依赖做校验,如果你直接修改 package.json 文件,或者是指定了一个非严格的版本号,在运行的时候都会做更新检查,防止遗漏。 值得注意的是,因为 npm-install 会进行依赖对比和校验,在安装新包的时候需要带上 --save 参数。否则,在自动更新 shrinkwrap 描述之前,脚本会自动移除多余的依赖包,导致你新安装的包被删除。 升级依赖包
package.json 文件中指定了一个非严格的版本号的依赖在运行 npm-install 的时候会做自动更新检查,无需指定版本号,如果你不希望进行自动更新,请在 package.json 中使用严格版本号。 删除依赖包
可以看到,在实际使用中没有引入额外的流程,对开发者基本没有学习的负担。但仍然注意,不建议开发者执行 小结通过引入 shrinkwrap 文件,我们可以较好的管理项目的依赖关系,让上线变得更轻松。需要注意的是,尽管相关工具可以帮助你减化工作流程、可靠的分发依赖描述,但工具不能取代功能测试;每次升级依赖版本之后,我们仍然应该进行相关测试来确保项目能可靠的运行在该环境中。 如果使用@th507/npm-shrinkwrap或者npm-shrinkwrap-install有任何问题欢迎给我提 issue。 本文没有涉及如何优化上线前的安装过程,缩短依赖构建时间,这个问题留给专门的文介绍 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |