[译] 回顾 ESLint 的成功

• 原文地址：Reflections on ESLint's success
• 原文做者：Nicholas C. Zakas
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：薛定谔的猫
• 校对者：H2O-2、warcryDoggie

回顾 ESLint 的成功

难以置信，我在 2013 年 6 月构思开发了 ESLint，7 月第一次对外发布。熟悉的读者可能还记得，ESLint 最初主要设计目标是运行时加载的检查工具（linter）。在工做中我看到咱们的 JavaScript 代码中的一些问题，但愿能有一些自动化的手段避免这些问题再次出现。

在 ESLint 发布后的 2 年半里，它的受欢迎程度大大增长。上个月的 30 天在 npm 上就有超过 1 500 000 次下载，这是当初平均月下载量只有 600 时我未曾想象的。

全部这一切发生了，然而过去 2 年我患上了很严重的莱姆病，几乎没法离开个人房子。这意味着我不可以外出参加会议和聚会来宣传 ESLint（前 2 年我但是会议常客）。但不知为什么，ESLint 得到了普遍关注，而且继续收到欢迎。我以为是时候回顾其中原因了。

JavaScript 使用量增长

过去三年，咱们看到浏览器上 JavaScript 的使用量持续增长。根据 HTTP Archive[3]，如今网页的 JavaScript 比 2013 年增长了 100 KB。

Chart - Increasing JavaScript Usage in Browsers 2013-2016

另外一个因素是 Node.js 的爆炸性流行。之前 JavaScript 仅限于客户端使用，而 Node.js 使另一些开发者也可以使用 JavaScript。随着运行环境拓展到了浏览器和服务器端，JavaScript 工具需求天然增长了。因为 ESLint 能够用于浏览器和 Node.js 上的 JavaScript，迎合了这一需求。

检查工具更加流行

因为 JavaScript 工具的需求增长，对 JavaScript 代码检查的需求也随之增长。这很容易理解 -- 你编写的 JavaScript 代码越多，就越须要更多保障，避免一些常见错误。自 2013 年中以来 npm 上 JSHint、JSCS、ESLint 的下载量显示了这一趋势。

Chart - Increasing downloads for all JavaScript linters

JSCS 和 ESLint 几乎是同时建立的，将它们各自的增长轨迹与更早一些的 JSHint 进行对比能够看到一些颇有趣的地方。到 2016 年初，JSHint 在 JavaScript 代码检查领域有着优点地位，JSCS 和 ESLint 也在增加。最有趣的是这三个工具的下载量都在增加，说明每个月下载检查工具的人多于更换的人数。

因此 ESLint 确实迎合了开发者对 JavaScript 代码检查需求增长的大趋势。

ES6/Babel

在过去的四年里，ECMAScript 6 的人气一直在稳定增加，这也使 Babel 得到了极大成功。开发者不用等浏览器和 Node.js 的正式支持就可使用 ECMAScript 6 语法，这也须要 JavaScript 工具的新特性支持。在这一点上，JSHint 对 ECMAScript 6 特性支持不足，显得有些落后了。

另外一方面，ESLint 有一个巨大的优点：你能够用其它的 parser 来代替默认的 parser -- 只要它的输出与 Esprima（或 Espree）兼容。这意味着你能够直接使用 Facebook 的 Esprima 支持 ES6 的 fork （如今已再也不维护）来检查你的 ES6 代码。Espree 如今也已经支持 ES6 了（主要来自 Facebook 的 fork）。这使得开发者能够很方便的使用 ES6。

固然，Babel 并无止步于支持 ES6 -- 它一样也支持实验特性。这就须要不但支持 ES 标准特性，还有其它开发中的特性（stage0 ~ stage4）。所以 ESLint 的 parser 可配置性就很重要了，由于 Babel 成员建立的 babel-eslint[4] 在其基础上进行封装，以便 ESLint 可以使用。

不久之后，ESLint 就成为了使用 ES6 或者 Babel 的人推荐的检查工具，这得益于容许兼容 parser 替换默认 parser 的设计决策。

如今，ESLint 安装时大约有 41% 使用了 babel-eslint（基于 npm 下载量统计）。

React

讨论 ESLint 的流行离不开 React。React 的一个核心特性就是支持在 JavaScript 中嵌入 JSX，而其它检查工具起初都不支持这一特性。ESLint 不但在其默认 parser 支持 JSX，用户也能够经过配置使用 babel-eslint 或者 Facebook 的 Esprima fork 来支持 JSX。React 用户也所以开始使用 ESLint。

咱们收到不少在 ESLint 自己加入一些 React 特有规则的请求，可是原则上我不但愿有库专有的规则 -- 由于这会带来巨大的维护成本。2014 年 12 月，eslint-plugin-react[5] 引入了许多 React 专有规则，很快获得了 Recat 开发者的欢迎。

后来在 2015 年 2 月，Dan Abramov 写了一篇文章《Lint like it's 2015》[6]。这这篇文章中，他介绍了 ESLint 在 React 中的应用，并给出了高度评价：

若是你从未据说过 ESLint -- 它就是我一直想要 JSHint 成为的那样。

Dan 也介绍了如何配置使用 babel-eslint，提供了极有价值的文档。明显能够看到这是 ESLint 的一个大的转折点：月下载量从 2015 年 2 月的 89,000 到 2015 年 3 月的 161,000 -- 增加了近一倍。从这以后到如今，ESLint 经历了一个快速增加的阶段。

如今，eslint-plugin-react 在 ESLint 安装中使用率有 45%+（基于 npm 下载量统计）。

可扩展性是关键

从一开始，个人想法就是 ESLint 自己是小核心工具，做为大生态的中心。个人目标是经过容许足够的扩展使 ESLint 永不过期：即使没法提供的新特性，ESLint 仍然能够经过扩展得到新功能。虽然如今 ESLint 尚未彻底知足个人设想，但已经很是灵活：

• 你能够在运行时增长新规则，这使得任何人均可以编写本身的规则。为了不天天花费大量时间处理用户想要各类预料外的规则，我将其视为关键所在。如今，没有什么阻止用户编写本身的规则。
• parser 的可配置性使 ESLint 能够处理任何和 Espree 兼容的格式。正如上文所述，这也是 ESLint 流行的一个重大缘由。
• 配置可分享，全部人均可以发布和分享配置，很是便于不一样的项目共用相同配置（ESLint 安装中 eslint-config-airbnb 的使用率有 15%）。
• 插件系统 人们能够很方便的经过 package 分享规则，文本处理器，环境和配置。
• 良好的 Node.js API 能够很方便的用于构建工具插件（Grunt，Gulp等），也可用于建立零配置的检查工具（Standard，XO等）。

我但愿 ESLint 将来能够提供更多的可扩展性。

听取社区反馈

我很是努力作到的事情之一就是：听取 ESLint 社区的反馈。虽然开始有些执拗于对于 ESLint 最初的设想，后来我意识到了众人的智慧。听到一样的建议次数越多，就越有多是须要考虑的痛点。在这一点上我如今好多了，社区的不少好的想法也促成了 ESLint 的成功：

1. parser 可配置 - 直接来自 Facebook的建议，他们但愿将 Esprima fork 用于 ESLint。
2. JSX 支持 - 起初我很是反对默认支持 JSX。但有持续不断的建议，我最终赞成了。如上文提到的，这一点也成为了 ESLint 成功的关键。
3. 可分享配置 - 来自 Standard 和其它基于 ESLint 的封装，它们的目标是使用特定的配置来运行 ESLint。看起来社区确实须要一种简便的方式来分享配置，所以这个特性诞生了。
4. 插件 - 起初加载自定义规则的惟一方式是，从文件系统使用命令行选项 --rulesdir 加载。很快人们开始在 npm 发布本身的规则。这样使用起来很痛苦，而且很难同时使用多个 package，所以咱们增长了插件以便可以方便的分享。

很明显，ESLint 社区关于这个项目的成长有许多极好的想法。毫无疑问，ESLint 的成功直接受益于它们。

群众基础

ESLint 发布以来，我写了两篇相关文章。第一篇发表在个人我的博客，第二篇在去年 9 月发表于 Smashing 杂志。除此以外，对 ESLint 的推广仅限于 Twitter 和 管理 ESLint Twitter 帐户。若是我愿意花心思去作些演讲的话，我确定会在推广 ESLint 上作的更好。可是由于我没有，我决定放弃尝试去推广它了。

然而我很欣喜的发现人们开始讨论 ESLint，写关于它的文章。起初是一些我不认识也没据说过的人。不断有人写文章（好比说 Dan），人们也在各类会议和聚会上讨论 ESlint。网上的内容愈来愈多，ESLint 很天然的也更加流行了。

一个有趣的对比是 JSCS 的成长。最开始 JSCS 获得了 JSHint 的宣传 -- JSHint 决定去除全部代码风格相关的规则，而 JSCS 则做为这些规则的替代品。所以当 JSCS 遇到问题时，会提到 JSHint 团队成员。有了这个领域的巨头支持，早期一段时间内，JSCS 的使用远超于 ESLint。第一年的一段时间内，我曾一度觉得 JSCS 会碾压 ESLint，让我许多夜晚和周末的工做失去意义，然而这一切并无发生。

强大的群众基础支持着 ESLint，最终帮助它获得了巨大成长。用户带来了更多用户，ESLint 也由此得到了成功。

关注实用性而非竞争

这是 ESLint 一路走来我最骄傲的事情之一。我历来没有说过 ESLint 优于其它工具，历来没有要求人们从 JSHint 或 JSCS 转向 ESLint。我主要说明了 ESLint 能更好的支持你编写自定义规则。到今天为止，ESLint README 里面这样写（在 FAQ）:

我不是说服你 ESLint 比 JSHint 更好。我只知道 ESLint 在个人工做中比 JSHint 更好。极小可能性你在作相似的工做，它可能更适合你。不然，继续使用 JSHint，我固然不会劝说你放弃使用它。

这一直是个人立场，如今也是 ESLint 团队的立场。一直以来，我始终认为 JSHint 是很好的工具，它有着不少优点 -- JSCS 也同样。不少人很是满意于使用 JSHint 和 JSCS 这一对组合，对他们来讲，我鼓励他们继续使用。

ESLint 关注于尽量有用，让开发者来决定是否适合他们。全部决策都基于有用性，而非与其它工具竞争。这个世界能够有不少检查工具的空间，没必要只有一个。

耐心

我之前说过[8]，如今开源项目间彷佛有一种不理性竞争：对人气的关注高于一切。ESLint 是一个项目从诞生到成功的很好的例子。在项目诞生初的近 2 年里，ESLint 的下载量远低于 JSHint 和 JSCS。ESLint 和 社区的成熟都花费了时间。ESLint 的“一晚上成名”并非发生在一晚上，它经历了持续不断的基于有用性和社区反馈的改进。

优秀的团队

我很幸运有很优秀的团队为 ESLint 作贡献。因为我没有太多精力和时间在 ESLint 上，他们作了不少工做。一直令我吃惊的是我历来没有当面见过他们，也没有听过他们的声音，但我很期待可以天天和他们对话。因为我须要恢复健康，他们永恒的激情和创造力使得 ESLint 可以继续成长。虽然我一我的开始了 ESLint 这个项目，但他们无疑是它可以发展达到目前的人气的缘由。

很是感谢 Ilya Volodin, Brandon Mills, Gyandeep Singh, Mathias Schreck, Jamund Ferguson, Ian VanSchooten, Toru Nagashima, Burak Yiğit Kaya, 和 Alberto Rodríguez，谢谢大家的大量工做。

结论

有许多因素致使了 ESLint 的成功，我但愿经过分享它们，能给其余人建立成功的开源项目提供一个指引。最值得作的事情，一点幸运，其余人的帮助和对要实现的东西的一个清晰的愿景，这就是全部关键。我坚信若是你关注于创造一些有用的东西，愿意付出辛苦的工做，最终将获得应得的回报。

ESLint 也在继续成长和改变，团队和社区也是。期待 ESLint 的将来。

References

1. ESLint (eslint.org)
2. Introducing ESLint (nczonline.net)
3. HTTP Archive Trends 2013-2016 (httparchive.org)
4. babel-eslint (github.com)
5. eslint-plugin-react (github.com)
6. Lint like it's 2015 (medium.com)
7. ESLint: The Next Generation JavaScript Linter (smashingmagazine.com)
8. Why I'm not using your open source project (nczonline.net)

免责声明：文中任何观点都属于 Nicholas C. Zakas 本人全部，不表明雇主、同事，Wrox Publishing、O'Reilly Publishing或其余人。

---

【译注】：本文发表于2016-2-9，如今 JSCS 团队已经加入了 ESLint，文中有些数据也已经再也不准确，但文章关注点不在这些，因此再也不从新更新。但愿这篇文章对开源做者有所参考！Enjoy it!❤️

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、React、前端、后端、产品、设计 等领域，想要查看更多优质译文请持续关注 掘金翻译计划。