管理node依赖是前端开发过程中会遇到的问题。
在Node.js项目开发的时候,我们也经常需要安装和升级对应的依赖。虽然 npm 以及语意化的版本号 (semantic versioning, semver) 让开发过程中依赖的获取和升级变得非常容易, 但不严格的版本号限制,也带来了版本号的不确定性。主要的问题可能有三个:
npm 建议使用 semver 的应用程序版本,但这也完全依赖第三方包遵守这一规则。如果你依赖于的包不遵循 semver ,或者依赖的包的新版本有重大更改(而你使用了 ^
的宽泛版本安装),这潜在可能是会导致问题的。
另一个问题的出现是由于 npm 安装依赖的机制。npm 的安装包是有层次结构的,手动控制要安装的软件包的版本号可以实现,但是你只能在 package.json 使用精确的版本号控制你的直接依赖包,但那些多层以上的依赖就没办法控制了;一个第三方包不严谨的版本依赖生命可能破坏你的依赖管理。
在开发阶段执行得到的版本,和后续部署时得到的可能是不一致的,更不可控的是,你依赖的第三方包也有这样的情况会导致潜在的上线风险。
如果要控制上线的风险,我们就必需要解决这个问题,这时候,推荐使用 npm shrinkwrap
这个命令来解决问题。
这个命令在node 5版本之后改成了npm install的时候自动生成package-lock.json,其功能和npm-shrinkwrap.json是一致的,只不过shrinkwrap是手动生成的,在此请各位注意。
关于package-lock.json/npm-shrinkwrap.json
npm install / shrinkwrap
可以按照当前项目 node_modules 目录内的安装包情况生成稳定的版本号描述。
比方说,有一个包 A
{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
}
还有一个包 B
{
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
}
以及包 C
{
"name": "C",
"version": "0.0.1"
}
你的项目只依赖于 A,于是 npm install
会得到这样的目录结构
A@0.1.0
`-- B@0.0.1
`-- C@0.0.1
这时候,B@0.0.2 发布了,这时候在一个新的环境下执行 npm install
将得到
A@0.1.0
`-- B@0.0.2
`-- C@0.0.1
这时候两次安装得到的版本号就不一致了。而通过 install/shrinkwrap 命令,我们可以保证在所有环境下安装得到稳定的结果。
在项目引入新包的时候,或者 A 的开发者执行一下 npm install / shrinkwrap
,可以在项目根目录得到一个 package-lock.json/npm-shrinkwrap.json 文件。
这个文件内容如下
{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": {
"version": "0.0.1",
"dependencies": {
"C": {
"version": "0.0.1"
}
}
}
}
}
shrinkwrap 命令根据目前安装在node_modules的文件情况锁定依赖版本。在项目中执行 npm install
的时候,npm 会检查在根目录下有没有 package-lock.json/npm-shrinkwrap.json 文件,如果文件存在的话,npm 会使用它(而不是 package.json)来确定安装的各个包的版本号信息。
这样一来,在安装时候确定的所有版本信息会稳定的固化在 package-lock.json/npm-shrinkwrap.json 里。无论是A,B 和 C中的版本如何变化,或者它们的 package.json 文件如何修改,你始终能保证,在你项目中执行 npm install
的到的版本号时稳定的。
在开发中使用 shrinkwrap
在开发过程中,引入一个新包的流程如下
npm install PACKAGE_NAME@VERSION --save
获取特定版本的包
测试功能
测试功能正常后,执行 npm install/shrinkwrap
把依赖写入 package-lock.json/npm-shrinkwrap.json 文件
在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述
升级一个包的流程应该是这样
npm outdated
获取项目所有依赖的更新信息
npm install PACKAGE_NAME@VERSION --save
获取特定版本的包
测试功能
测试功能正常后,执行 npm install/shrinkwrap
把依赖写入 package-lock.json/npm-shrinkwrap.json 文件
在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述
删除一个包的流程如下
npm uninstall PACKAGE_NAME --save
删除这个包
测试功能
测试功能正常后,执行 npm install/shrinkwrap
把更新的依赖写入 package-lock.json/npm-shrinkwrap.json 文件
在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述
比一般的安装多了一步手工生成 package-lock.json/npm-shrinkwrap.json 文件。在实际工作中,有时候我们会忘记这一步,导致上线时候没有获取到依赖包的特定版本。
小结
通过引入 package-lock.json/npm-shrinkwrap.json 文件,我们可以较好的管理项目的依赖关系,让上线变得更轻松。需要注意的是,尽管相关工具可以帮助你减化工作流程、可靠的分发依赖描述,但工具不能取代功能测试;每次升级依赖版本之后,我们仍然应该进行相关测试来确保项目能可靠的运行在该环境中。