去年，anfu 谈论了他对 Prettier 跟 Eslint 的看法-为什么我不使用 Prettier，同样在那个时候，VUECONF 2022 也分享了关于对前端项目 linter 跟 formatter 的实践- Vue 项目配置：最佳实践与个人偏见，彼时，这些经验与分享让我重新审视这些代码规范化工具。一年后的今天，笔者写下这篇文章，期望以这段时间的总结与收获帮助各位读者理解跟使用这些工具。
大部分前端入门者一般会困惑于 npm 包 Eslint、Prettier 跟 vscode 拓展 Eslint 、Prettier这个四个工具，之后陷入工具包的配置难题，这个时候，已经脱离了使用工具的初衷，因为我们为了使用这些工具，需要去阅读文档、配置工具、解决 Eslint 跟 Prettier 之间的冲突问题，之后为了加快 Eslint 的修复速度，还去引入 lintstage，这些工具真的让我们的开发变简单了么？实则没有。笔者认为，在 formatter 跟 linter 代码的过程中，大部分开发者对整体流程没有一个清晰的认知，从而导致了工具的不正确使用与滥用。
工具定位
简单来说，Prettier 是代码格式化工具，Eslint 的代码风格跟质量检测工具。这些工具都提供了命令行对项目代码进行操作，执行 Prettier 的命令可以格式化整个项目的代码，执行 Eslint 可以检测出项目中出现的问题，同时 Eslint 也具备一定的修复功能。
那为什么还会出现 Prettier 跟 Eslint 的 IDE 拓展呢？Prettier 包的执行需要命令行去格式化，IDE 拓展 Prettier 把这种格式化的功能添加到了 Vscode 上，开发者通过 Vscode 就可格式化指定的片段代码或者文件。同样上图中红色波浪线那种表明代码质量问题的 UI 效果需要 IDE 拓展 Eslint 赋予给 Vscode。
目前业界实践出现的问题
琐碎配置
各种配置文件会提高项目的门槛，如果需要管理这些文件，首先需要把 User 跟 WorkSpace 分开，然后配置 Prettier 拓展，Eslint 拓展，之后为了项目整体格式化跟项目质量检测还需要配置脚本执行，同时.vsocde 下的 setting.json 任何更改都会影响其他同学的开发体验。
工具混用导致的一系列问题
Prettier + Eslint 同时作为格式化工具会出现冲突，这点 anfu 在博客做过相关描述，具体来说就是 本地格式化通过 Prettier 格式化后，在 lint 自动修复是 Eslint 修复的地方跟 Prettier 的规范有冲突。 为了解决冲突，部分实践通过顺序 format 进行格式化。
json
"lint-staged": {
"*.{js,ts,jsx,tsx}": [
"prettier --write",
"eslint --fix"
],
"*.vue": [
"stylelint --fix",
"prettier --write",
"eslint --fix"
],
"*.{less,css}": [
"stylelint --fix",
"prettier --write"
]
},同时两个工具同时运行检查和格式化,对性能是双重打击。这会导致保存和提交代码变得明显缓慢,降低开发效率，为此还需引入 lint-staged 提高效率。
个人最佳实践
0 拓展配置 + prettier（formatter） + eslint（linter）
以团队角度来讲，拓展+ setting.json 本身一方面造成部分内存的使用，一方面增加了同时之间的维护与理解成本，该文章的目的是不安装拓展的情况下，进行项目协同开发，仓库角度来讲，线上部署的代码跟 .vscode 上配置的 setting.json 半毛钱关系都没有。
为什么我建议使用 Prettier ，Eslint 一方面会因为检测出的 error 中断 git hook 的向下执行，一方面 Eslint 无法对 max-len 进行 format，github.com/eslint/esli...
以开发者的角度，只期望工具对代码风格进行 rewrite，也就是只修改格式，不要修改代码内容，足够简单即可。linter 在开发中不应频繁使用，使用 Eslint format 代码本身就存在 linter 的滥用， linter 的 lint 过程本质上是检查代码中的异味，linter 规则的制定需要团队成员共同接受，在此之上解决冲突规则的覆盖，成本并不是很高，相反如果将 lint 下沉到每次 commit，反而会增加团队中每个开发人员开发人员的负担。
hook 的时机
- formatter的时机
什么时候期望代码格式化呢，formatOnSave 应该是大部分开发者第一个想到的，但是如果就有些同学没在这个 hook 格式化怎么办呢，部分开发者会想到 pre-commit，事实上还可以再晚一点，只要保证远程仓库的代码是格式化后的代码就行，按照 CI 的角度来说，formatter 的最佳时机就是者每次 push 前，对项目进行整体的格式化，目的就是保证 repo 上的代码是按照团队的 格式化规则组织的，而没必要每次 commit 都去格式化代码。
- linter 的时机以及如何处理异味
这个就见仁见智了，笔者看来，linter 的最佳时机为项目发版或者每次迭代前，或者不放心的话再提前一点，保证 test 分支 prod 生产环境上的代码必须是经过质量检测且修复的就行。
笔者的最佳实践可以总结为
仓库维度的原子化的 formatter + 定期的 linter
仓库角度来说，并不关心每个 IDE 上怎么配置，如何制定规范，仓管只要求每个成员 pull 跟 push 上的代码是格式化的，可读的。至于 linter，看公司跟团队规范就可以，保证交付部署产物一定是通过 linter 扫描且通过的就可以。