在有 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年代里，在那个还只有黑白电影的年代，一位瘦高的英国绅士正站在剧幕正中的讲演台上侃侃而谈。
