在有 package-lock
的项目,我们可以使用 npm ci
来替代 npm install
.
前言
在阅读本文之前,你应该先了解以下知识(点击链接可以快速了解相关知识):
为什么使用 npm ci
最近出现了Jenkins构建成功,但是项目却运行失败的情况,排查问题的时候发现是Jenkins构建时安装依赖的版本不对导致的构建失败。
本身这种情况发生的概率比较小,因为我们在安装依赖的时候默认都会在依赖的版本号前面加上 ^
来限制安装依赖的大版本。
这次的问题是在安装 Taro
时版本的不对齐导致的。如果我们需要使用 Taro
,除了安装 @tarojs/cli
之外,我们还需要安装一些依赖(使用 Taro CLI
创建项目时会自动安装),比如:@tarojs/components
、 @tarojs/runtime
、 @tarojs/taro
等等。
Taro
要求我们在安装这些依赖的时候 Taro CLI
版本与项目中 Taro
相关依赖的版本保持一致,否则无法正常运行。关于这项规则的详情可以查阅Taro 官方文档.
在我们的 package.json
中,我们只是使用了 ^
来限制这些依赖的大版本更新,这样的限制对于 Taro
来说是不足够的。
原本我们的方案是去掉 Taro
相关依赖的前面的 ^
,这样这些依赖的版本就完全固定了,除非我们手动修改它,这样的方案当然是没有问题的。
但除此之外,我们应该还有另一个方案。别忘了,我们在本地运行和调试项目的时候是完全正常的,也就是说我们本地安装的依赖是没问题的。
所以另一个方案就是让 Jenkins 构建时安装和使用与我们本地相同的依赖,如果你说直接将 node_modules
推送到代码仓库中,这当然也能解决问题。但我不敢保证,你的同事听到你的这番言论会不会臭骂你两句,然后踹你一脚。
此时我们应该想到另一个可能被我们遗忘的小机灵鬼:package-lock.json
。这可是控制 node_modules
文件夹中所有依赖的源头啊。
是的,我们完全可以通过锁定问题的源头来解决问题,即锁定 package-lock.json
,让 Jenkins 在构建安装依赖时使用和我们本地依赖一致的包,这样我们的问题就可以解决了。
而实现这一目标的的一个优雅工具就是:npm ci
.我们可以使用 npm ci
取代 npm install
,就像图里所演示的这样,将构建脚本里的 npm install
换成 npm ci
,这样就可以实现我们所需要的效果了:
关于使用 npm ci
的场景,它应该是这样的:
在有
package-lock
的项目,我们可以使用npm ci
来替代npm install
.
npm ci vs npm install
至于 npm ci
相较于 npm install
还有哪些区别与优势,可以参考这篇文章:npm ci 命令.这篇文章已经清晰地讲述了它们之间的联系。
我是尾巴
当我写完这篇文章的时候,心里突然感觉非常的舒畅。这像是20世纪50年代里,在那个还只有黑白电影的年代,一位瘦高的英国绅士正站在剧幕正中的讲演台上侃侃而谈。