自 ESLint 的第一个版本以来，我们一直基于开源的 Esprima 解析器构建。 这样做使我们能够获得一个即插即用、可用于生产环境的解析器，我们可以在此基础上构建我们梦想中的 linter。 这意味着我们可以花更少的时间担心解析 JavaScript 代码，而花更多的时间弄清楚使用该代码的最佳方法。 ESLint 是围绕 Esprima 生成的 SpiderMonkey AST 构建的，这个决定一直以来都对我们很有利。
今年早些时候，当我们尝试在 ESLint 中包含 ECMAScript 6 和 JSX 支持时，我们遇到了很多问题。 Esprima 的 ECMAScript 6 支持尚未发布，并且已经好几个月没有新版本发布了。 与此同时，Facebook 创建了自己的分支，其中同时包含 ECMAScript 6 和 JSX 支持，因此我们尝试使用它来代替，希望能作为即插即用的替代品。 不幸的是，我们发现它的工作方式与 ESLint 当前基于的 Esprima 1.2.2 版本之间存在一些关键差异。 这些差异使得我们无法继续前进，因为它不仅需要对我们自己的代码库进行大规模更改，还需要对 ESLint 生态系统中的第三方插件进行大规模更改。 我们尝试提交错误报告以获得这些问题的答案，但不幸的是无法解决它们。
我们还研究了使用 Acorn，另一个出色的项目，它可以生成 SpiderMonkey AST。 不幸的是，ESLint 已经发展到依赖于某些 Esprima 特定的功能，例如 token 的表示方式以及注释如何附加到节点。 拥有相同的 AST 是不够的，我们要么必须更改大量代码，要么创建一个适配器，该适配器必须在可预见的未来保持同步。
经过深思熟虑，我们认为正确的做法是创建我们自己的解析器，我们可以控制它。 这使我们与 JSHint 和 JSLint 保持一致，因为两者都有自己的解析器（这些解析器没有从项目中分离出来）。
进入 Espree
Espree 是 Esprima 的一个分支，从 1.2.2 版本开始。 这是 ESLint 使用的最后一个稳定发布版本，我们希望尽可能保持一切正常运行。 计划是快速实现所有 ECMAScript 6 和 JSX，以便 ESLint 可以支持这些广受欢迎的变体。 我们正在以一种非常审慎的方式进行此操作，一次拉取一个功能，并根据一套新的测试进行验证。 通过这样做，我们希望避免 Esprima Harmony 分支的重大更改，以便 ESLint 可以继续使用新语法。
与 ESLint 项目本身一样，我们致力于快速响应问题和拉取请求，并将随着增强功能和错误修复的完成而频繁发布版本。 事实上，在过去一周我们已经发布了 四个版本。
当前的短期目标是拥有一个 API，它可以作为使用它的项目中 Esprima 的即插即用替代品。 下一个版本的 ESLint 将基于 Espree 而不是 Esprima 构建。
功能标志
Esprima 和 Espree 之间最大的区别之一是使用功能标志来打开或关闭额外的语言功能。 尝试实现 ECMAScript 6 的项目常常因为感觉需要在发布之前实现庞大规范的每个部分而放慢速度。 Espree 的方法不同：我们实现规范的每个部分，并将其隐藏在功能标志后面。 这意味着当在解析器中实现新的 ECMAScript 功能时，不会引入向后不兼容的更改。 您需要选择加入使用该新功能，否则，它将保持关闭状态。
查看 使用说明 以获取有关当前可用功能标志的更多信息。
您如何提供帮助
您可以通过多种方式帮助 Espree 项目
其他问题
将来您会生成 Shift AST 吗？
Shift AST 规范今天刚刚发布，因此我们将评估其反响和未来的技术细节。 假设这是 ESLint/Espree 社区想要的更改，我们将研究可选支持 Shift AST 的工作。 此决定还将受到整个社区对 Shift AST 规范的接受程度的影响。
您将支持 JSX 吗？
是的。 我们收到了足够多的 JSX 支持请求，因此将其作为 Espree 中的功能标志包含进来是有意义的。
您将支持 Flow 类型或 TypeScript 吗？
JavaScript 的可选类型世界中正在发生很多事情。 目前，现在确定赢家并决定哪种类型系统是正确的实现似乎还为时过早。 我们将继续密切关注这一领域，看看是否能达成共识。 如果是这样，我们很乐意实现可选类型。
您多久发布一次？
至少每月一次，希望更频繁，直到实现所有 ECMAScript 6 和 JSX。 然后我们将专注于收到的任何错误报告，并进行补丁发布来修复它们。
