当 ESLint 最初创建时，想法是拥有一小部分 20-30 个核心规则，以便每个人都可以入门，然后让社区构建自己的规则来填补任何剩余的空白。然而，我们确实继续实施核心规则，因为这似乎很有帮助，以至于今天有 280 个核心规则。在任何给定时间，超过一半的未解决问题和拉取请求都与规则相关，这些规则占用了团队的大量时间。
ESLint 现在受益于蓬勃发展的以规则为中心的插件生态系统，例如 eslint-plugin-node、eslint-plugin-import、eslint-plugin-react 和许多其他插件。像 astexplorer.net 这样的工具和大量的教程使开发人员比以往任何时候都更容易编写自己的规则。核心团队不再需要构建大量的基本规则，因此我们可以将时间优先用于期待已久的核心功能，例如并行 linting，这将使整个社区受益。我们正在对如何优先考虑内置规则的更改进行一些调整，但与往常一样，如果某个规则不太适合您的情况，我们鼓励您将其修改为自己项目的自定义规则，并与社区的其他成员分享。
变更内容是什么？
展望未来，我们正在对处理规则问题和拉取请求的方式进行以下更改
- 新规则受到限制 - 我们只接受与前 12 个月内达到 stage 4 的新 ECMAScript 功能相关的新规则。社区依赖 ESLint 来帮助他们学习使用新语言功能的正确方法，我们希望继续这样做。我们将不接受与新 ECMAScript 功能无关的建议或偏好的新规则。
- 不接受仅禁用语法的的新规则 - 我们已经有了
no-restricted-syntax，它应该适用于大多数情况。否则，人们可以创建自己的规则。我们确实有一些仅禁用语法的遗留规则（例如no-undefined），我们将保留这些规则，但我们不会添加更多。 - 风格规则被冻结 - 我们不会向风格规则添加更多选项。我们已经了解到，没有办法满足每个人的个人偏好，而且大多数规则已经有很多难以理解的选项。风格规则是指与间距、约定以及通常不突出错误或改进方法的任何内容相关的规则。2021-01-29 更新：我们在 README 中澄清，我们仍将支持新添加的 ECMAScript 功能。
- 新的规则选项必须由社区成员实施 - 人们仍然可以为现有的核心非风格规则提出新的选项，我们将像往常一样评估它们。但是，这些批准的选项需要由社区实施，并且不会成为核心团队开发路线图的一部分。
那么错误呢？
我们将继续评估所有核心规则（包括风格规则）的错误。如果可以验证错误，我们将继续将其作为我们正常维护程序的一部分进行修复。
感谢您的理解
我们知道这对 ESLint 的运作方式来说是一个改变，我们感谢您的理解。ESLint 由一名兼职开发人员和一支志愿者团队维护，因此我们的带宽有限。我们正在进行这些更改，以便更好地利用我们可用于维护项目的时间。如果您想帮助我们，请考虑为项目贡献力量或 捐款。
