久未更新的老化工具，遍布在 82% 的开源项目里

摘要：现代开源项目的维护永无休止，但不同于项目刚发布时的重视，许多维护人员在之后的更新工作中总有疏忽，那么究竟有多少开源项目中还在使用老旧的工具版本呢？

链接：https://blog.trunk.io/82-of-open-source-projects-suffer-from-tool-rot-e766bdf449a2
声明：本文为 CSDN 翻译，未经允许禁止转载。
作者 | Eli Schleifer
译者 | 弯月 责编 | 郑丽媛
出品 | CSDN（ID：CSDNnews）

软件项目的保质期很短。

在提交落到 main 分支上的那一刻，软件就变质了：运行时和编译器发布了新版本，依赖项发布了错误修复以及新功能，相关 API 弃用等等。

优秀的工程组织会尽可能使用最新版本的工具，毕竟随着使用的语言发展和工具改进，运行已弃用的版本意味着放弃了很多自动化的可能性。

维护现代项目是一项永无休止的工作，如果不加以管理就会出现问题。每个维护不善的项目最终都将深受工具“腐烂”的困扰，久而久之，我们使用的工具会逐步老化，并出现各种问题。

各种开发工具在刚被代码库采用时，都是新发布且闪闪发亮的，但一旦设置好，就会被遗忘在角落。通常开发工具都没有明确的所有者或负责人，无法得到及时的更新，直至工具老化出现问题。

为了掌握开源世界中工具过时的普遍程度，我快速调查了一下整个 GitHub 开源代码库中老版 ESLint 的使用情况。我之所以选择 ESLint，是因为它无处不在，也是最容易升级的工具之一，你可以直接利用 npm 更新，非常简单。

下面，我们就来看一看这款更新工作量近乎零的工具在实践中的老朽程度。为了方便分析，我使用了 GitHub 仍处于技术审查阶段的代码搜索工具。

31,000 多个代码库仍在使用 ESLint 7

ESLint 是一个很方便分析的目标，因为你可以利用 package.json 文件检查版本。首先，我想了解有多少个代码库甚至连 ESLint 主版本都处于落后状态，仍在使用版本 eslint:7.x.x。所以，我进行了如下搜索：

path:**/package.json "\"eslint\": \"7"

如上所示，有 31,000 多个代码库仍在使用 ESLint 7。最新主版本 ESLint 8 发布已经一年多了，但仍有大量项目在使用旧版本。这意味着，在过去的一年中他们都没有享受到工具和规则集的重大改进。

此外，我们发现还有其他大量使用过时版本的项目，甚至还有代码库使用零版本的 ESLint。以下是各个开源项目使用 ESLint 的版本分布详情：

图：使用旧版本 ESLint 的项目数，以及每个版本的发布年份

这里必须指出，ESLint 4.x 及之前的版本都很容易受到正则表达式拒绝服务攻击（Regular Expression Denial of Service attack，即 ReDoS）。

如你所见，我们发现在使用 ESLint 的开源项目中，有 9500 个很容易受到该攻击的影响。诚然，很多人在很久以前创建代码库后就放弃了，但上述列表中不乏一些大型科技公司，他们也在使用不安全的工具版本。

工具腐烂无处不在

此外，我还深入其他主流生态系统中工具腐烂的情况，特别是 Python 格式化程序 black 以及通用格式化程序 prettier。

prettier 目前最新的版本是 v2.7.1，black 是 v22.10.0。上图中显示的数据量远低于实际情况，因为我们可以通过多种方式引用 prettier，而这个结果只是通过 package.json 设置直接运行 prettier 的项目。

如何保持工具最新

技术人员喜欢创建产品并解决问题。我们可以借助一些机器人保持工具最新，但这些机器人也需要手动配置，而且还有可能引入大量的拉取请求垃圾邮件。机器人解决方案只是自我管理开发工具中很小的一部分，我个人更喜欢使用 trunk check。

所有自动发布解决方案都需要使用最好的工具，还需要编写这些工具的脚本并维护它们。当然，你可以将所需的开发工具拼凑在一起，也可以使用 trunk 等现成的解决方案。