Complete rewrite of ESLint
原文翻译自eslint官方git库issue中，ESlint的作者Nicholas C. Zakas的讨论
介绍
ESlint诞生于2013年，这意味着到明年它就十岁了。在这十年间，人们书写javascript的方式已经有了翻天覆地的变化，同时我们也一直在对ESlint进行增量更新。这对我们很有帮助，因为我们能够相当快地跟上变化，并且构建与 2013 年相同的基本核心。然而我不相信继续如此去做增量更新可以满足ESlint的下一个十年。
目标
我一直在考虑我希望 ESLint 下一步去哪里，并提出了几个目标。目前这些都非常抽象，但它们在这里，没有特定的顺序：
1、船新的代码库。
从一个全新的 repo 开始将使我们能够在必要时继续维护 ESLint 的当前版本，同时确保我们在新版本上进行非破坏性更改。
2、带有类型检查的ESM。
我不想使用TypeScript 中重写，因为我相信 ESLint 的核心应该是 vanilla JS，但我的确认为从头开始重写可以让我们在 ESM 中编写并使用带有 JSDoc 注释的 tsc 来对项目进行类型检查。包括在packages中发布类型定义。
3、运行时无关
ESLint 应该能够在任何运行时运行，无论是 Node.js、Deno、浏览器还是其他。我想专注于创建一个与运行时无关的核心包 (@eslint/core)，然后是运行时特定的包（@eslint/node、@eslint/browser 等），它们具有任何给定运行时所需的任何附加功能。是的，这意味着官方支持的浏览器版本！
4、语言无关
ESLint 的核心没有任何内容需要特定于 JavaScript。配置计算、实现规则等，全部都是通用的。所以我想从核心中提取特定于 JavaScript 的功能并将其作为插件，也许叫做@eslint/js?
5、新的公共APIs
由于我们多年来采用的增量方法，我们现在的公共 API 非常混乱。从未设想过 ESLint 在 Linter 类（最初是一个 linter 对象）之外拥有一个公共 API，我们一直在对此进行hack。现在我们有一个 ESLint 类和一个 Linter 类，这很令人困惑，而且它们都不仅仅是 lint。我想完全重新考虑公共 API 并提供适合构建 StandardJS 等东西的高级 API，以及遵守单一职责原则的 VSCode 插件和低级 API，可以进行更多创造性的混合和匹配。
6、基于Rust的替代
一旦我们有了定义更明确的 API，我们就可以将部分换成基于 Rust 的替代方案以提高性能。这看起来像是为 Node.js 创建用 Rust 编写的 NAPI 模块，用 Rust 编写并编译成 WebAssembly，创建一个用 Rust 编写的独立的 ESLint 可执行文件来调用 JavaScript 部分，或其他方法。
7、全部异步
异步解析、规则……所有东西！我们在这方面取得渐进进展时遇到了麻烦，但从头开始构建我们可以让它按照我们想要的方式工作。
8、可插拔的源代码格式化
文体规则很麻烦，所以我想将源代码格式设置作为一个单独的功能。因为它是 ESLint，这个特性应该是可插入的，所以如果你愿意，你甚至可以插入 Prettier 来完成这个角色。
9、输出结果的reporter
当前的格式化程序范例是有限的：我们一次只能有一个，我们不能在结果完成时传输结果，等等。我想切换到类似于 Mocha 和 Jest 的reporter模型。
10、AST改变以自动修复
这是我们长期以来一直想要的。我认为它是对当前文本编辑自动修复的补充，而不是直接替代。
一些可能
这些是我脑海中尚未完全形成的一些想法，我不确定我们将如何实施它们，或者即使它们不一定是好想法，但它们值得探索。
- 使 ESLint 感知类型。这似乎是我们一直在努力解决的问题——我们只是没有任何方法知道变量包含什么类型的值。如果我们知道这一点，我们就能发现更多的错误。也许我们可以找到一种方法来为此消费 TypeScript 数据？
- 使 ESLint 感知项目。我们看到越来越多的人希望对周围的项目有一些感知，而不仅仅是独立文件。
typescript-eslint 和eslint-plugin-import都处理多个文件以获得项目的完整图片。弄清楚这在核心中是如何工作的似乎值得探索。 - 独立的 ESLint 可执行文件。凭借 Rust 调用 JavaScript 的能力，可能值得探索我们是否可以创建一个独立的 ESLint 可执行文件，无需安装单独的运行时即可分发。Deno 还能够将 JavaScript 编译成独立的可执行文件，因此甚至不需要 Rust 来尝试。
实现途径
无论我们做出什么决定，总体方法都是从小处着手，而不是立即尝试与当前的 ESLint 100% 兼容。我认为我们已经加入了太多可能并不常用的功能，因此我们将专注于在添加之前获得核心体验，例如，每个现有的命令行选项。
下一步
这显然不是一个完整的提案。需要有一个（大量的）RFC（译者注：请求意见稿） 来考虑人们对下一代 ESLint 的所有目标和想法。我在这里的目的只是开始对话，征求团队和社区对他们希望看到的内容的反馈，然后弄清楚如何从那里向前推进。 此列表绝不是详尽无遗的。这是为 ESLint 的未来添加所有疯狂愿望清单项目的地方，因为进行完全重写意味着考虑到我们现在甚至无法考虑的事情。
