咱們爲何須要 lock 文件

前言

從 Yarn 橫空出世推出 lock 文件以來，已經兩年多時間了，npm 也在 5.0 版本加入了相似的功能，lock 文件愈來愈被開發者們接收和承認。本篇文章想從前端視角探討一下咱們爲何須要 lock 文件，以及它的一些成本與風險，固然其中一些觀點對於後端也是適用的。

爲何須要 lock 文件

之因此須要 lock 文件，我以爲主要有 4 個緣由：

確保各環境依賴版本的一致性

軟件開發通常有着好幾個環境，一般包括本地開發環境、集成測試環境、預發佈環境以及線上環境。各環境依賴版本不一致一般是 bug 的一大來源，你們可能碰到過「在個人電腦上是好的」這種問題，也許就是依賴版本不一致致使的。這種問題一般很難定位，由於你很難肯定究竟是本身的問題仍是依賴的問題。這也是 Yarn 推出 lock 文件的初衷之一，使用了 lock 文件，你在排查問題時至少能夠排除依賴版本不一致這個因素。

語義化版本並不絕對可靠

一些開發者不肯意使用 lock 文件，一個主要緣由是他們但願基於語義化版本號讓依賴自動升級，認爲只要選擇的依賴可靠，大版本不變化就能夠放心升級。在絕大多數狀況下這麼作不會有問題，可是也有意外狀況，好比：

React 在 v16.4.0 對 getDerivedStateFromProps 的調用時機進行了調整。React 在 v16.3.0 引入了這個 API，最初只有在父組件引發的重渲染過程當中會被調用，v16.4.0 調整爲在全部渲染過程當中都會被調用。若是你在不知情的狀況下（自動）把 React 從 v16.3.0 升級到了 v16.4.0，那麼極端狀況下你的應用就會出問題。

雖然只有在很極端的狀況下你纔會碰到相似問題，可是這種問題原本就是不怕一萬就怕萬一。

可控的升級依賴

如今經過 webpack 把依賴單獨提取爲一個 vendor.js 是個很常見的作法，由於依賴變動相對來講沒那麼頻繁，再配合上強緩存，能夠作到即便發佈了新版本，用戶也可使用緩存的 vendor.js 而沒必要從新下載。一般咱們的應用不止一個依賴，這些依賴確定也不是同一時間發佈更新，若是不使用 lock 文件讓其自由更新，可能會致使 vendor.js 緩存失效屢次（每一個依賴更新都會致使緩存失效）。若是使用 lock 文件就能夠積累一段時間，讓多個依賴集中更新，甚至跳過一些小版本更新，從而提升 vendor.js 的緩存命中率。

安全問題

幾個月前 ESLint 發生了一個安全事故，一個攻擊者竊取了 ESLint 維護者的 npm 帳戶，併發布了惡意版本的 eslint-scope 和 eslint-config-eslint（都是更新的小版本），其中前者是 babel-eslint 和 webpack 的依賴。若是沒有使用 lock 文件，那麼你就極有可能中招，ESLint 過後也建議開發者使用 lock 文件來避免自動安裝新版本。

成本

使用 lock 文件天然會增長一點項目的維護成本，由於依賴不會再自動升級，因此須要項目維護者每隔一段時間手動進行升級。另外若是兩我的同時修改了依賴，解決 lock 文件的衝突也是一件很麻煩的事。

可是手動升級依賴也有一些額外的好處，至少你升級每一個依賴時都要去看一下它的 change log，這樣能夠對每一次升級作到心中有數，這也有助於你掌握依賴的發展趨勢。好比前文提到的 React 的例子，只要你在升級時看一眼它的 change log，就很容易避開可能出現的問題。

風險

我惟一能想到的風險就是依賴版本固化問題，若是你使用了 lock 文件又沒有花時間跟精力去維護它，那麼你的項目就很容易陷入依賴版本固化的問題。若是過久沒有升級依賴，你當前使用的版本跟最新版差異太大，升級就會很困難，考慮到現實成本問題，可能就永遠不會升級了。

可是若是不使用 lock 文件就能徹底避免這個問題嗎，我想也不必定。不使用 lock 文件最多也只能在同一個大版本範圍內自動升級，若是依賴升級了大版本，你沒有花時間去升級，也會碰到一樣的問題。只是相對於不使用 lock 文件，問題暴露的晚一些而已。