在长期运行中,使用--fix标志自动化ESLint是否是一个好的实践,还是会产生问题?
例如,我正在使用npm
,并在"prestart"
脚本中运行ESLint。这意味着每次我运行npm start
时ESLint都会运行,并修复代码中可修复的错误。这可能会引起什么问题?
在长期运行中,使用--fix标志自动化ESLint是否是一个好的实践,还是会产生问题?
例如,我正在使用npm
,并在"prestart"
脚本中运行ESLint。这意味着每次我运行npm start
时ESLint都会运行,并修复代码中可修复的错误。这可能会引起什么问题?
npm start
时,实际运行的代码可能与你编写的代码不同。在启动应用程序之前,ESLint会对你的代码进行更改,这可能会导致意外行为(潜在地)。这取决于你的项目设置和应用程序部署方式。--fix
运行ESLint时,它会尝试不破坏你的代码功能来修复代码,但任何时候在编写代码和运行代码之间操作你的代码都会使你面临改变代码库行为的风险。ESLint会确保不会以可能破坏/更改任何内容的方式自动修复你的代码,但错误/意外事件可能会发生,从而改变你的代码足以使其表现不同。顺便说一下,这里有一个关于自动修复和如何更改的有趣讨论。
如果你将ESLint作为npm test
套件的一部分运行,并且只有在通过你的lint规则后你的应用程序才会部署,那么这不是太大的问题(因为这只会在本地发生,而不会发生在你的部署应用上;你正在避免部署与你的样式指南不匹配的代码)。--fix
可以让人们按照自己的方式编码,同时通过半自动化方式维护一致的风格并避免代码库中的“问题模式”。虽然它不能修复每一个规则,但它可以使团队开发变得更加顺畅。如果需要,甚至可以在git pre-commit hook中运行此自动修复,以确保提交的代码是已修复的版本。
--fix
标志可能会破坏代码的例子吗?因为我想不到任何情况。据我所知,ESLint 仅修复空格和分号... - Gimy boyaeqeqeq
仅修复静态可验证的情况:https://github.com/eslint/eslint/pull/7389。然而,错误有时会发生,自动修复有时可能会破坏代码。ESLint将其作为优先事项来修复这些情况,因为它们被报告。 - Ilya Volodinnpm start
之前或提交/推送代码之前自动修复,因为您可能想要检查“已修复”的代码。 - Nick Bartlett