咱们为何须要 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 文件，问题暴露的晚一些而已。