还在用 npm install ? 试试 npm ci 吧!

3,217 阅读3分钟

在有 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,这样就可以实现我们所需要的效果了:

WX20210427-132922@2x.png

关于使用 npm ci 的场景,它应该是这样的:

在有 package-lock 的项目,我们可以使用 npm ci 来替代 npm install.

npm ci vs npm install

至于 npm ci 相较于 npm install 还有哪些区别与优势,可以参考这篇文章:npm ci 命令.这篇文章已经清晰地讲述了它们之间的联系。

我是尾巴

当我写完这篇文章的时候,心里突然感觉非常的舒畅。这像是20世纪50年代里,在那个还只有黑白电影的年代,一位瘦高的英国绅士正站在剧幕正中的讲演台上侃侃而谈。

参考链接

  1. npm ci 命令.