ESLint 团队在最近的一次更新中，宣布了一个重大的决定：他们将在下一个次要版本中，正式废弃其核心的格式化规则，这些规则主要涉及代码的空格、分号、字符串格式等方面。这一决定是基于多年来维护这些规则所带来的各种问题和挑战，以及专门的源代码格式化工具的普及和优势。作为一个长期使用 ESLint 的开发者，我对这一决定感到既惊讶又欣赏，也对专门的源代码格式化工具充满了期待和信任。
历史和发展
ESLint 是一个非常优秀的 JavaScript 代码质量工具，它可以帮助我们检查代码中的错误和潜在问题，提高代码的可读性和可维护性。我从 ESLint 刚刚诞生的时候就开始使用它，见证了它的成长和发展。ESLint 最初为了与 JSHint 竞争，加入了大量的格式化规则，以满足用户的个性化需求。后来，ESLint 还合并了 JSCS 项目，进一步增加了格式化规则的数量和复杂度。这些规则让我可以按照自己的喜好来配置代码的格式，让我的代码更加美观😁和一致🚀。
问题和挑战
但是，随着 JavaScript 的语法和风格的不断变化，ESLint 面临了越来越多的请求，要求添加更多的选项和异常来支持各种风格指南。这给 ESLint 团队带来了巨大的维护负担，也影响了其他更有价值的工作的进展。ESLint 的格式化规则还存在一些问题，如规则之间的冲突、用户的不切实际的期望、团队和贡献者的缺乏兴趣、一致性问题等。这些问题随着 ESLint 的发展而变得难以解决。ESLint 团队在这篇博客 ( eslint.org/blog/2023/1… )中详细解释了他们放弃格式化规则的原因和过程，我非常理解和支持他们的决定。
专门的源代码格式化工具，如 Prettier 和 dprint，能够更好地理解整个文件，并应用一致的格式。虽然用户可能无法像使用 ESLint 那样控制每个细节，但换来的是简单和快速的体验。我相信，专门的源代码格式化工具能够更好地适应 JavaScript 的变化，也能够更好地与 ESLint 协作，让我可以专注于代码的质量，而不是代码的格式。
关键的技术原因
ESLint 的规则设计是原子化的。它们不会相互影响，更加不会访问其他规则的信息。这反映了 ESLint 的设计原则和架构，也说明了为什么 ESLint 的格式化规会受到限制。反过来，专门的源代码格式化工具能够更好地理解整个文件，更适合这个场景。
今后的影响
- ESLint 团队将能够更专注于代码质量方面的工作，而不是花费大量的时间和精力在维护格式化规则上。这将提高 ESLint 团队的效率和满意度，也将提高 ESLint 的质量和功能。
- ESLint 的用户将需要选择是否使用专门的源代码格式化工具，或者使用第三方插件来替代 ESLint 的格式化规则。这将需要用户做出一些权衡和调整，也将影响用户对 ESLint 的体验和感受。Nicholas C. Zakas（ESLint 作者）建议用户尝试使用专门的源代码格式化工具，或者使用
@stylistic/eslint-plugin-js或@stylistic/eslint-plugin-ts插件，这些插件由 Anthony Fu 维护，包含了 ESLint 核心和typescript-eslint中废弃的格式化规则。这些工具能够让用户的代码更加美观和一致，也能够与 ESLint 更好地协作，让用户的代码更加高质量和高效率。 - 专门的源代码格式化工具将获得更多的关注和使用，也将面临更多的需求和挑战。这将促进这些工具的发展和改进，也将增加这些工具的责任和压力。我希望，这些工具能够不断完善和优化，也能够保持开放和友好的态度，与 ESLint 和其他代码质量工具形成良好的生态和合作，让 JavaScript 的开发者们享受到更好的编程体验。
结语
本文介绍了 ESLint 团队为什么要放弃核心的格式化规则，而转向使用源代码格式化工具的原因和过程，以及这一决定对 ESLint 的发展和变化的影响。截止发稿时间，ESLint 官宣了新的大版本的发布计划，ESLint v9.0.0 将分两个阶段发布（预计 Alpha 版本将在 12 月或 1 月发布），包含多项重大的破坏性变更，旨在提高性能，减少安装大小，更新配置格式，移除过时的功能，增加新的规则和功能。
如果您对本文有任何意见或建议，欢迎在评论区留言。谢谢您的阅读和关注！
