我的React应用程序是使用CRA（React-Scripts v4.0.0）引导的，并且我想添加一个代码格式（特定于特定的），该代码必须在将更改进行更改为Git Repo之前必须格式化代码。
我知道ESLINT是反应式订阅的依赖性，并且使用'eslint-webpack-plugin'（默认启用）在WebPack配置中完成。 <
现在，如果我想扩展我的原始eslint-config，我可以安装/写一个新的eslint-config，例如'eslint-config-prettier' -config。这将完成这项工作。
假设这将在不安装任何额外依赖项的情况下更新当前的Eslint-Config，并且在更改代码时，每次（使用更新的配置）都会抓取应用程序代码。并会尽可能地提出编译错误。
我已经看到Web上的多个教程，再次安装ESLINT作为DEV依赖关系，然后在预先承诺的挂钩中使用它来固定刺伤问题，然后在此之后依次运行更漂亮的代码格式化。是否在必要的预制挂钩中安装和运行 eslint -fix ？还是多余的？
My react application is bootstrapped using CRA(react-scripts v4.0.0) and I want to add a code formatter (prettier to be specific) that must format the code before committing the changes to my git repo.
I know that eslint is a dependency of react-scripts and linting is done using 'eslint-webpack-plugin'(default enabled) inside the webpack configuration. Snippet from CRA github | React Scripts webpack config
Now, if I want to extend my original eslint-config I can install/write a new eslint-config like 'eslint-config-prettier' and add it to my extends key inside eslint-config. And this would do the job.
Assuming, this updates the current eslint-config without installing any extra dependencies and as normal, would lint the application code every time (with updated config) when the code is changed. And would throw compilation errors as it should.
I have seen multiple tutorials over web installing eslint again as a dev dependency and then using it inside pre-commit hooks for fixing linting issues and then running the code formatters like prettier sequentially after that. Is installing and running eslint --fix in a pre-commit hook necessary at all? or is it redundant?
发布评论
评论（1）
即使基于CRA的React应用程序停止了棉被错误的汇编，也不会严格阻止用户犯下不良代码。
如果在阶段文件或整个项目中存在不可用的棉布错误，则添加 eSlint -fix 预先承诺的挂钩停止用户的提交推动不良代码。
虽然，在CRA的情况下，再次安装ESLINT是冗余的，因为它已经作为反应标记的依赖性。
Even if CRA based react application halts the compilation on lint error, it does not strictly prevent the user from committing the bad code.
Adding the eslint --fix pre-commit hook halts the user's commit if there is an unfixable lint error present in staged files or the whole project (depending on the command, file glob pattern provided) thus prevents accidental push of bad code.
Although, installing eslint again in case of CRA is redundant as it is already present as a dependency for react-scripts.