如何與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，而後從新安裝一遍，至關於把全部（直接依賴+間接依賴）模塊所有更新一遍。

原文連接：查看原文