今天是美好的一天，因为我开始将 ESLint 集成到我们的代码库中！我是一只有趣的码猴。我喜欢良好的编码实践，例如 linting、用户/技术/产品文档、测试、可访问性和安全性。这些主题通常优先于交付工作代码，因为代码可以在没有我列出的任何编程热情的情况下工作。但是，如果实现了所有这些实践，代码将很少被破坏（或被破坏），并且是更可靠的代码。为什么不从一开始就创建“可靠的工作代码”？
为什么我喜欢林婷？
Linting 将帮助您尽早发现常见错误。 Linting 规则可以识别不良的编码实践，因此开发人员不会将它们引入项目中。例如，Linting 可以识别何时使用 const 而不是 let 或影子变量。
通过 linting 来防止不良代码，值得进行多次调试不良代码的冲刺。
我的挑战
我们有一个现有的代码库，有许多开发人员做出了贡献。在我安装 ESLint 并运行报告后，代码有超过 5K 的 linting 违规。我寻找与 NextJS、typescript、A11y 和 JavaScript 一起使用的最佳 linting 规则。由于存在如此多的违规行为，我决定逐步寻找错误。 ESLint 具有自动修复功能，但永远不要在预先存在的代码库上运行该功能并期望它能够工作。不，不，没有年轻人。我们必须迭代！
我将关键规则设置为“错误”，其余规则设置为“警告”或“关闭”。然后我重新运行该报告，以确定在再次部署我们的代码之前应该修复哪些问题。在手动修复所有错误并且可以构建代码之后，我运行了单元测试以确保我们仍然通过所有内容。良好的 linting 永远不会破坏代码。 linting 充其量是为了支持开发人员。帮助初级开发人员学习更好的编写代码的方法，因为他们必须这样做。
在我的所有错误都被识别并修复或忽略之后，我们就可以部署并知道我们的代码与我们“今天”所能得到的一样好。现在代码库已经修复，我们将来可以使用“auto-magic-fix”，并相信它有 50/50 的机会修复 linting 错误。
我的学习
看来ESLint长大了！它将不再支持更多的代码格式化规则，这些规则应该由代码格式化库而不是 linting 库维护。自 v9 起，ESLint 已弃用许多功能，并将大部分（如果不是全部）移至 Stylistic！
我使用 Prettier 进行代码格式化，并且 Typescript 在 Stylistic 中具有标志支持，因此我坚持使用 ESLint v8.53.0，这样我就可以保持 ESLint 的卓越代码格式化。但我最终将不得不进入 9，所以这只是“把罐头踢到路上”。
编码快乐！
