ESLint的缓存机制及其在CI中的应用

背景

ESLint是一个前端、Node领域中流行的代码规范检查工具，使用起来很方便。

之前为了强制推行代码规范，我在CI任务中加入了ESLint检查。保障了规范的同时，也引入了痛点：CI的时长延长了2~3分钟左右。因为现在开发的工程体量比较大，ESLint会占用很多的内存、CPU资源，且运行时间较长。

在了解到ESLint有缓存机制之后，我尝试过在CI中加ESLint缓存，但是效果不太理想。怀疑是缓存未能命中，所以我尝试分析了下ESLint中的缓存逻辑。

ESLint的缓存机制

ESLint在命中缓存时，执行速度是极快的。而在无法命中缓存时，可能就需要消耗很多时间了。

ESLint中与缓存相关的选项有三个：--cache、--cache-file和--cache-location，其中--cache-file作用与--cache-location类似，都是用于修改默认的cache存储位置，--cache-file已经被废弃。

在运行eslint的时候，加上--cache参数，就会自动生成一个.eslintcache文件，用于储存上次缓存的结果。

.eslintcache文件的内容格式如下所示：

1[
2  {
3    "commitlint.config.js": "1",
4    "packages/frontend/babel.config.js": "2"
5  },
6  {
7    "size": 71,
8    "mtime": 1605752807612,
9    "results": "1230",
10    "hashOfConfig": "1231"
11  },
12  {
13    "size": 1489,
14    "mtime": 1605752807627,
15    "results": "1232",
16    "hashOfConfig": "1231"
17  },
18]

它的整体结构是一个数组。

其中第一项元素是一个"文件路径->数组序号"的对象。根据它的Value中的序号，在数组中找到相应的元素，即为它的属性。

可以看出文件里面存储了：size、mtime等属性，eslint在决定文件是否发生变更时，使用的是file-entry-cache中的默认方式，即根据文件大小(size)和最后修改时间(mtime)决定文件是否发生了变更。

另外还有hashOfConfig属性，是存储的配置文件的HASH值，这样当配置文件发生变化时，所有的缓存都会失效。

缓存失效的原因

在CI中，每次执行任务时，大部分的文件都没有发生变化，所以 size 属性肯定是没变的。那么为什么会出现缓存未命中的情况？原因就在于 mtime 发生了变化。

git 在 clone / fetch 的时候，并没有保证 mtime 的值与文件最后提交时间相同，而是使用了 git clone 时的系统时间。所以每次CI执行时，mtime发生了变更，继而导致file-entry-cache的缓存失效，eslint重新执行。

从这里也可以看出，只要解决了 mtime 的问题，就可以解决缓存失效的问题了。

解决缓存失效问题

解决缓存失效问题，核心问题还是在file-entry-cache中。它支持两种方式判断缓存是否命中，一是根据mtime和size，二是根据md5 checksum值。

理论上来说，如果eslint使用hash码的方式，也就不会受mtime影响了。但是考虑到一要改eslint的逻辑，二是计算hash码涉及到大量I/O，应该也有不小的消耗，所以还是优先考虑从mtime着手处理。

要使一个文件在多次clone或fetch之间mtime不发生变化，可以将其设置为它在Git中的最后提交时间。直观的做法是遍历每一个文件，使用git log获取其最后提交时间，然后再设置mtime。

这种方式理论上可行，但是实际操作中应该会有性能优化空间。

好在有人提供了现成的脚本工具git-restore-mtime，可以直接拿来用。这个脚本虽然也要花费一些时间，但时间不长，可以接受。

这样一来，原来的eslint命令就变成了：

1$ git restore-mtime
2$ eslint --cache .

还有一些其它的方法，如将mtime修改为文件的hash值。这个实际上还是md5 checksum的套路，性能上不会很优。

git-restore-mtime的安装和使用

git-restore-mtime依赖于Python3，需要先安装好Python3。

配置好python3之后，根据系统不同选择如下的安装命令之一：

Debian/Ubuntu系列：

1sudo apt install git-restore-mtime

RedHat/Centos系列：

1sudo yum install git-tools

如果是在其它的系统上，如alpine。则可以直接从Git仓库中复制最新的 git-restore-mtime 文件到PATH中即可，如复制到 /usr/local/bin/git-remote-mtime。

使用的方法很简单，运行 git restore-mtime 即可。

总结

ESLint的cache很高效，但是要注意在CI环境中可能会有缓存无法命中的情况，可以考虑使用git-restore-mtime来解决无法命中的情况。