我们为什么需要 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-scopeeslint-config-eslint(都是更新的小版本),其中前者是 babel-eslintwebpack 的依赖。如果没有使用 lock 文件,那么你就极有可能中招,ESLint 事后也建议开发者使用 lock 文件来避免自动安装新版本。

成本

使用 lock 文件自然会增加一点项目的维护成本,因为依赖不会再自动升级,所以需要项目维护者每隔一段时间手动进行升级。另外如果两个人同时修改了依赖,解决 lock 文件的冲突也是一件很麻烦的事。

但是手动升级依赖也有一些额外的好处,至少你升级每个依赖时都要去看一下它的 change log,这样可以对每一次升级做到心中有数,这也有助于你掌握依赖的发展趋势。比如前文提到的 React 的例子,只要你在升级时看一眼它的 change log,就很容易避开可能出现的问题。

风险

我唯一能想到的风险就是依赖版本固化问题,如果你使用了 lock 文件又没有花时间跟精力去维护它,那么你的项目就很容易陷入依赖版本固化的问题。如果太久没有升级依赖,你当前使用的版本跟最新版差别太大,升级就会很困难,考虑到现实成本问题,可能就永远不会升级了。

但是如果不使用 lock 文件就能完全避免这个问题吗,我想也不一定。不使用 lock 文件最多也只能在同一个大版本范围内自动升级,如果依赖升级了大版本,你没有花时间去升级,也会碰到同样的问题。只是相对于不使用 lock 文件,问题暴露的晚一些而已。

阅读 2.2k

懒博客
前端,JavaScript, CSS

Love open free web

246 声望
7 粉丝
0 条评论
你知道吗?

Love open free web

246 声望
7 粉丝
宣传栏