如何与NPM package-lock.json愉快地玩耍

欢迎关注富途web开发团队，php , 前端须要你。缺人从众

富途一每天的在成长，小伙伴们也愈来愈多。前端的更新迭代，一直都在进行。Vue已经做为前端的主要开发框架，想一想2年前，我还在写JQ，后面写angular.js。前端打包也从原来的打包文件提交入Gitlab库，到后来接入jenkins（打包文件不入库），再到今天的Gitlab CI。

勇于尝试，推进落地执行。

今天给你们分享一下前端打包接入Gitlab CI遇到的坑。

另外附带一个用于下载Gitlab CI 打包文件的组件：查看组件

背景

对的，最近写文章都会交代一下背景。由于按标题的套路，这本应该是一篇教程类的文章，但这种文章其实挺无趣的。之因此想写这篇，是由于确实碰到了一些很麻烦的事情。闲言少叙，咱们进入正题。

最近咱们前端代码打包正在接入Gitlab CI，使用Docker来做为Executor，也就是在Docker中进行前端代码打包，而后收集打包结果，以备发布时使用。打包时Docker镜像很天然地就选择了官方Node镜像，最新版本（Node 10）。

一开始咱们尝试性地接入了几个项目，有使用NPM scripts进行打包的，也有使用Gulp进行打包的，一切都很正常。可是昨天在接入一个新项目，使用Gulp打包的时候，却忽然碰到了报错：

$ gulp gitlab-ci
gulp[85]: ../src/node_contextify.cc:631:static void node::contextify::ContextifyScript::New(const v8::FunctionCallbackInfo<v8::Value>&): Assertion `args[1]->IsString()' failed. Aborted ERROR: Job failed: exit code 134 复制代码

看了一眼这个错误信息，一会儿就发现，这并非来自JS层的错误，而是来自Node原生层，这就超出了个人理解范围了。

模块版本兼容问题

经过搜索，首先找到一篇中文的解决方案：升级node10后gulp报错的解决办法。文中给出了以下解决办法：

rm -fr node_modules
rm -fr package-lock.json
npm cache clean --force
npm install
复制代码

因此这是什么原理呢？没看到文章有解释，另外这文章自己也写得不是很清楚。抱着半信半疑的态度，在CI的脚本中加上了npm cache clean --force，结果问题依旧。

接着搜索了一下，很快发现一些和这个问题有关的issue：

• nodejs/node: node 10.0.0安装模块时core dump
• nodejs/node: 新发布的版本与Gulp ^3.9.0不兼容
• gulpjs/gulp: 将graceful-fs的升级合并回Gulp 3
• gulpjs/gulp: node 10中崩溃
• isaacs/node-graceful-fs v3.x分支与Node.js master不兼容
• isaacs/node-graceful-fs v3.0.11依赖natives 1.1.1，后者与node 10不兼容

经过npm ls，一会儿就看到了natives模块的版本是1.1.1，因而定位到真正的问题：gulp依赖vinyl-fs，vinyl-fs依赖graceful-fs，graceful-fs依赖natives，而natives在1.1.3以前都不兼容Node 10。

那么解决方案就简单了，想办法升级一下模块不就行了？

如何升级间接依赖

首先想到的是Gulp是否有解决这个问题，npm info gulp看了一下，发现最新版本是3.9.1，而后npm ls一下，发现本机装的已是3.9.1了，也就是说，Gulp根本没有升级的可能。那要如何升级这个间接的依赖呢？

这里我绕了个弯子，package.json中直接依赖的模块没法升级，npm update也不能搞定。因而想到，若是显式安装一下这个模块，是否是能解决问题？

npm install natives@1.1.3
复制代码

安装完以后还要在package.json中将直接依赖natives删除（由于我并不直接依赖它，留着没用）。而后再次查看依赖：

▶ npm ls natives
seed@1.0.0 /Users/TooBug/work/oa/learn/frontend
└─┬ gulp@3.9.1
  └─┬ vinyl-fs@0.3.14
    └─┬ graceful-fs@3.0.11
      └── natives@1.1.3
复制代码

此次对了。

可是，这个操做我是在本机进行的，这个操做到底改了什么呢？若是去CI上再次执行npm install，会不会依然安装到旧版本呢？毕竟package.json并无任何改动。

因而翻看了一下git diff，发现了本文的主角package-lock.json被修改了，其中的natives由1.1.1变成了1.1.3。

"natives": {
    "version": "1.1.3",
    "resolved": "http://registry.npm.oa.com/natives/download/natives-1.1.3.tgz",
    "integrity": "sha1-RKV5vmRQfqLW7RygSpQVkVz3VVg="
},
复制代码

因而怦然大悟：原本npm在安装模块是是按语义化版本安装最新版的，可是在CI上却没有安装natives 1.1.3版本，而是安装了natives 1.1.1版本，这正是由于package-lock.json装版本锁定了，从而致使了与Node 10的不兼容问题。

这也能很好地解释，为何其它项目没有这样的问题，由于其它的项目在代码仓库中没有包含package-lock.json，在安装时天然就安装了natives 1.1.3版本。

因而再回头看一开始搜到的文章提出的解决办法：

rm -fr node_modules
rm -fr package-lock.json
npm cache clean --force
npm install
复制代码

实际上是很是有效的，由于它将package-lock.json直接删除了，而后从新安装一遍最新版本，生成新的package-lock.json，从而解决问题。

延伸：如何正确地在项目中使用package-lock.json

最后，也补充说明一下package-lock.json的正确用法。（虽然我知道，但仍是不当心踩坑了。若是不清楚它的用法的话，可能会在坑里待更长时间爬不出来。）

首先，须要确保npm的版本在5.6以上，由于在5.0 - 5.6中间，对package-lock.json的处理逻辑更新过几个版本。5.6以上的才是符合认知的逻辑。

而后，在项目中若是没有锁版本的必要，能够不使用package-lock.json，在安装模块时指定--no-lock便可。

若是项目中有package-lock.json，则安装模块时会以这个文件中指定的版本和地址为准，直接下载安装。（除非它和package.json中指定的版本不相符。）

最后，若是已经锁定了版本的状况下，须要更新直接依赖，则直接安装指定版本，package.json和package-lock.json都会同步更新。若是须要更新间接依赖的话，则须要像本文这样，手工安装一下，保证package-lock.json被更新到。或者若是其它模块的锁定并非那么重要时，也能够直接删除package-lock.json，而后从新安装一遍，至关于把全部（直接依赖+间接依赖）模块所有更新一遍。

原文连接：查看原文