首先prettier和eslint之间没任何关系，可以完全按照两个不同的东西来看待。
一、代码规则与代码样式
为了好理解，代码的风格统一我们可以暂且理解分为两部分，一部分是代码规则，一部分是代码样式。代码规则往往不影响代码样式，而代码样式往往也不影响代码规则，这是很多人会感到疑惑的部分。下面我们来举例：
const a = 30; 有分号
const a = 30 无分号
const name = '张三'; 单引号
const name = "李四"; 双引号
const obj ={"age":1}; 对象key有引号
const obj = {age:1}; 对象key无引号
无论是单引号还是双引号；亦或是有分号还是无分号，它都不会影响代码的运行，并且通常通过配合编辑器插件进行一键格式化即可自动规范。这样的例子我们称之为代码的样式。接下来我们看看什么是代码的规则：
1.在对象中定义重复的key
const obj = {age:1,age:2,age:3};
2.存在无法到达的代码
function test(){
return return;
//这行代码无法到达
const a= 1+1;
}
3. 代码嵌套过深
if(){
if(){
for(){
[]. map()
}
}
}
4.继承未调用supper()
5. 使用逻辑过深的三元
a==1?b==1?2:3
以上类似的例子不胜枚举，代码样式类型的约束，通常通过一键格式化的配置就能做到，而代码使用上的错误，则很难通过一键格式化办到。
二、当爹又当妈的ESlint
在lint版本8.0之前，不仅负责代码规则的检查，还肩负着代码样式规范的责任。以前我们在使用eslint时，通常会经过以下步骤：
1. 安装 npm i eslint
2. 配置项目文件 .eslintrc
3. 安装vscode eslint拓展
4. 将vscode代码格式化方式改为ESlint
经过以上步骤，通常就完成了lint的配置进入了使用流程。这里容易引起困惑的就是lint既负责了代码样式格式化，又负责了代码规则限制。 上面我们聊到，代码样式通常用一键格式化可以办到，但是如果是代码使用上的错误，通过vscode一键格式化其实也是救不了你的，你还得手动修改。
这里就已经体现出lint又当爹又当妈的功能，只是很多人忽略了当自己在使用ESlint进行格式化时，这其实是lint的代码样式部分的支持在生效。
而当自己代码写错时，则忽略了一键格式化无效这个细节，这其实仍然是lint在抛出错误，只是这次是lint代码规则部分在生效，一般都下意识的手动就去改了，也不在乎这个错误是不是ESlint提示的。
三、ESlint拓展与ESlint之间的关系
实际上，即使我们不安装lint拓展，也不会影响lint是否生效。想要查看代码是否符合规范，运行npx eslint .就可以触发检查，并且在控制台抛出异常。
如果没有安装eslint拓展，那么它也只是影响你在vscode书写代码是否有及时的报红提示。 由此可见，vscode的ESlint拓展在Eslint规则生效层面并不是必须的。
ESlint拓展是基于编辑器开发，它只是基于vscode这个编辑器开发的拓展，它之所以能给你带来错误提示，是因为拓展在启动后，会优先检查本地npm中是否有eslint依赖，然后加载项目中的.eslintrc配置文件，最后利用vscode提供的编辑器能力为你在不符合规范的地方报红。
四、ESlint不干了
在eslint@8.53.0后,作者正式宣布lint不再支持代码样式方面的约束。代码样式与代码规则不一样的地方是：代码规则更多的是为代码代码可读性、正确率、规范统一方面做约束，这也就意味着糟糕的代码是可预见性的。而代码样式则是五花八门，每个人都有自己的想法。每个人都想要求作者将自己喜欢的代码样式风格约束作为配置加入到ESlint中，甚至多达300条。
ESlint极多繁杂的代码样式配置使得ESlint的维护负担极大，一大堆配置其实对程序员也不友好。关于作者对于这方面的声明和吐槽可以看移步至原文： eslint.org/blog/2023/1…
五、代码样式约束选手：prettier
既然eslint不再支持代码样式方面的约束，那么就需要一个替代者。 prettier 就是一个很好的插件。它专注于负责代码样式，而eslint将专注于代码规则的部分。这样一来，eslint的配置则会更清晰更简洁。
prettier的安装与eslint不同的是，prettier甚至不需要npm安装。我们只需要安装好vscode的prettier拓展，然后配置好.prettierrc.js。最后将你的vscode格式化配置改为prettier即可。
为何如此简单？
因为prettier只负责样式格式化，通常样式并不会影响代码执行的正确性。prettier一般不会报红，在你将默认格式化方式改为prettier后，每次手动格式化都会被prettier自动规范。
为什么eslint拓展需要寻找eslint的npm包，而prettier却不需要？
其实prettier拓展也是会去你项目里寻找prettier的npm包的，只不过当它无法找到时，则会使用prettier拓展自带的prettier版本，它本身就内置了（比eslint贴心）。 若你想自己掌控版本，可以自行安装prettier
六、ESlint与prettier的结合
虽然eslint@8.53.0后eslint不再参与代码样式的支持，但是还是有很多人在这个版本之前想要使用prettier，并且vscode配置了prettier格式化。那么可以通过安装eslint-config-prettier插件来屏蔽掉lint和prettier冲突的配置，优先让prettier配置生效。
eslint也并不是完全一下子抛弃了样式格式化支持，而是将这些功能配置抽离成了eslint插件单独维护，关于这部分的描述可以看我上面贴的作者原文。
写在最后
使用eslint进行代码规范的约束;使用prettier进行代码样式风格的约束。这已经成了现在主流的解决方案。别忘了在使用prettier的项目中将你的格式化配置改为prettier。
