使用“--fix”标志自动化 ESLint 会出现哪些问题？

Question

使用 --fix 标志来自动化 ESLint 是一个好的做法，还是从长远来看会产生问题？

例如，我npm在脚本中使用 and "prestart"。这意味着每次运行时 ESLint 都会运行npm start并修复代码中任何可修复的错误。这会导致什么问题？

Answer 1

这可能导致的唯一真正问题是最终运行的代码npm start可能与您编写的代码不同。您可以在启动应用程序之前让 ESLint 对代码进行更改，这可能（可能）导致意外行为。这取决于您的项目的设置方式以及应用程序的部署方式。

在ESLint 规则列表中，可以自动修复的规则旁边有扳手；它不仅仅可以改变间距和分号。虽然 ESLint（使用 运行时--fix）会尽力不破坏代码的功能，但只要您在编写代码和运行代码之间操作代码，您就会面临更改代码库行为的风险。ESLint 试图确保它们不会以破坏/改变任何行为的方式自动修复您的代码，但可能会发生错误/事故，这可能会改变您的代码，使其表现不同。顺便说一句，这里有一个关于自动修复及其可能如何改变的有趣对话。

如果您将 ESLint 作为套件的一部分运行npm test，并且除非您的 lint 规则通过，否则不会部署您的应用程序，那么这并不是什么大问题（因为这不会在您部署的应用程序上发生，只会在本地发生；您将保留如果发现代码与您的风格指南不匹配，则您的应用程序将停止部署）。

否则，--fix可以帮助人们按照自己想要的方式进行编码，同时保持一致的风格并半自动地避免代码库中的“有问题的模式”。虽然它并不能解决所有规则，但它可以使团队的开发更加顺利。如果需要，您甚至可以在 git 预提交挂钩中运行此自动修复，以便确保提交的代码是修复版本。

示例：Git 预提交 ESLint 挂钩