eslint
作用
eslint本质就是一个内置有解析器的工具，它可以将项目代码解析成AST，然后根据AST抽象语法树分析出代码里存在的问题然后给出警告或者报错。eslint的初衷就是在代码编写阶段尽早得发现存在的错误；除了语法检查外，eslint也具有一定的代码格式化能力，但是不是其能力的重心（prettier在代码格式方面更加专业）。
初始化
如果使用脚手架初始化项目，比如通过vite创建项目：pnpm create vite这样得到的项目模板都对eslint进行了初始化配置。
如果手动给项目配置eslint检查：
经过问答之后生成eslint的配置文件.eslintrc.cjs
配置项——parser & parserOptions
本身eslint的语法检查就是一个先对代码进行静态解析得到AST，然后再判断的过程。所以在eslint默认的解析器基础上，自然需要一些更高级的解析器来支持更新的语法以及语言，比如eslint的默认解析器是Espree，它只支持对es5的js进行解析，所以我们如果项目中使用了ts，Espree就不行了，自然需要用到更高级的（支持ts以及最新es版本的）解析器@typescript-eslint/parser。
更加准确的说，在配置文件中parser项的value为所使用解析器的模块名，如
通过parser我们指定了项目所使用的语法解析器，parserOptions就相当于给出解析器更详细的解析配置，比如如下配置，parserOptions就具体指定了@typescript-eslint/parser解析器应该支持最新版本的es标准（“ecmaVersion”: “latest”）以及项目的模块化标准为esModule（“sourceType”: “module”）
配置项——globals & env
globals是定义全局变量，规定他们可不可以重写以及是否被禁用，env就是一组globals预设（一组打包的globals配置），如下配置：
配置项——rules & plugins & extends
rules就是具体的eslint进行语法检查所依据的规则；但是官方只提供了关于标准js的检查规则，所以需要plugins来拓展规则集合，比如针对用Vite创建的react + Ts的项目，就通过react-refresh这个plugin拓展了eslint的规则，但plugins中拓展的规则默认不开启，所以plugins要与rules配合使用来拓展eslint的功能；但是我们总不可能把所有规则一条一条的写在rules中，extends就相当于一组配置好的rules与plugins组合，解决了这个痛点。
rules中的规则优先级最高，会覆盖拓展以及插件中引入的规则。
一般来说规则的值有三个值，只需控制是开启还是关闭：
off 或 0：关闭规则
warn 或 1：开启规则，warn 级别的错误 (不会导致程序退出)
error 或 2：开启规则，error级别的错误(当被触发的时候，程序会退出)
如"eqeqeq": “off”。有的规则有自己的属性，使用起来像这样：“quotes”: [“error”, “double”]。具体内容查看规则文档。
文件级别的配置优先级
我们的项目中可以存在多个eslint配置文件，那么文件进行eslint检查时，文件所处位置向上直至文件系统的根目录路径上所有的eslint配置文件都会生效，但是越”靠近“文件的配置优先级越高（可以理解为高优先级规则覆盖低优先级规则）。
如下，source.js使用配置A，但是test.js使用配置B和配置A，但是配置B中的规则会覆盖掉A中相同的规则。
配置项"root": true可以阻止继续递归的查找比较远的根目录。
package.json中也可以对eslint进行配置，所以项目中文件的eslint配置文件可以总结为：
与要检测的文件在同一目录下的 .eslintrc.* 或 package.json 文件
继续在父级目录寻找 .eslintrc 或 package.json文件，直到根目录（包括根目录）或直到发现一个有"root": true的配置。
vscode中的使用
在vscode中安装eslint插件之后，无需在命令行中手动执行eslint命令即可在编码时实时提供eslint语法检查，而且也可以开启eslint的代码格式化功能，需要进行如下vscode配置：
ctrl + shift + p打开搜索栏搜索settings.json配置文件，项目内生成.vscode文件夹，在其下的settings.json中新增配置：
意为对tsx语言进行保存时格式化。
支持的语言：
prettier
作用
prettier的作用就是代码格式化，可以理解为prettier把代码解析之后再按照预期的规则进行重新打印，并且支持各种语言，如JavaScript、 Flow、 TypeScript、 CSS、 SCSS、 Less、 JSX、 Vue、 GraphQL、 JSON、 Markdown等等
初始化 & prettier执行
pnpm i prettier -D安装之后，工程目录下新建.prettierrc.js配置文件以及.prettierignore忽略文件，这样就相当于告诉我们的工程我们使用了prettier，之后执行prettier格式化命令时即按照配置进行格式化，如npx prettier. --write格式化所有文件。
prettier 隐式忽略node_modules，并不需要将其添加到.prettierignore中
.prettierrc.js
配置就比较简单直观了，都是一条一条具体的格式化规则，如下配置中基本都是默认值：
vscode中的使用
安装prettier的vscode插件，安装之后我们可以右键需要进行格式化的文件然后选择prettier进行格式化。
自动化：
ctrl + shift + p打开搜索栏搜索settings.json配置文件，项目内生成.vscode文件夹，在其下的settings.json中新增配置：
eslint && prettier
最佳实践——解决eslint与prettier在代码格式上的冲突
因为eslint本身也具备对代码格式的控制与检查能力，所以不可避免可能会与prettier的代码格式冲突，比如eslint配置rules中对缩进的要求为2并在不满足时报错，.eslint.cjs：
.prettierrc.cjs：
那么我们在执行npx prettier . --write后进行eslint代码检查eslint .就会把所有缩进问题进行报错，检查不通过。
解决方案很简单——思路就是把prettier的规则复写进eslint中，并对原本eslint中的格式配置进行覆盖，这样就做到了eslint的格式化检查与prettier的格式化行为统一。
用社区的轮子即可：
extends的值为数组，后面的数组项会继承和覆盖前面的配置，所以完成了prettier规则对eslint规则的扩充和覆盖。
最佳实践——省略prettier格式化命令，eslint进行格式化与检查一步到位
完成上述操作本质是做到了 ESLint 会按照 Prettier 的规则做相关校验，也就是说先执行Prettier格式化后再执行eslint检查不会因为格式问题冲突而报错，但是还是需要运行 Prettier 命令来进行格式化。为了避免多此一举，社区也提供了整合上面两步的方案：在使用 eslint --fix（eslint错误修复） 时候，实际使用 Prettier 来替代 ESLint 的格式化功能。操作如下：
这个时候运行 eslint --fix 实际使用的是 Prettier 去格式化文件。在rules中添加"prettier/prettier": “error”，用意是编写代码时不符合prettier格式规范的编码eslint直接自动报错（结合vscode的eslint插件实时报错的能力）。
当然直接执行eslint --fix会没有反应，原因是eslint命令缺少目标文件，可以用–ext [文件拓展名,[文件拓展名]]的形式指定需要进行eslint修复以及检查的文件，比如react + ts项目中：
表示进行eslint检查的同时进行自动修复（–fix），针对的文件是以ts、tsx为拓展名的（–ext ts,tsx），还有一些错误打印相关的要求（–report-unused-disable-directives），代码执行不退出的可以容忍的警告数量为0。
eslint命令参数参考
最佳实践——覆盖vscode本地格式化配置（代码格式层面协作统一）
由于每个人本地的 VS Code 代码格式化配置不拘一格，在实际的项目开发中，多多少少会因为格式化问题产生争议。因此需要有一个统一的规范覆盖本地配置，editorconfig for vs code承担起了这个作用，只要在项目工程的根目录文件夹下添加.editorconfig文件，那么这个文件声明的代码规范规则能覆盖编辑器默认的代码规范规则，从而实现统一的规范标准。
一般我们都用prettier进行代码格式化，在vscode中Prettier读取配置的优先级即：
Prettier 配置文件，比如.prettierrc 、.prettier.config.js。
.editorconfig文件，用于覆盖用户/工作区设置。
.editorconfig举例：
最佳实践——Husky + lint-staged优化git工作流
husky基本使用
husky做的事情就是在git工作流的某个时机触发脚本，也就是git hook，比如我们在git commit之前进行eslint语法检查，eslint检查过程中报错或者警告太多是会中断指令（git commit）执行，所以这样就保证了提交到远程的代码是通过eslint检查的。
（配置详情查询husky官网）
安装依赖：
pnpm i -D husky
husky初始化：
csharp复制代码pnpm dlx husky-init
不同包管理工具初始化的命令不同，去husky官网指南查看即可。
执行如上命令后，项目里生成.husky文件夹，文件夹下有个pre-commit文件，内容如下：
前两行不知道具体啥用，猜测应该是husky内部使用，下面写的命令pnpm lint即为在commit之前需要执行的命令。同时因为husky初始化命令的执行，package.json的script脚本中多了一个"prepare": “husky install”，试了试用处不大，无心理会…
这里的git hook已经满足当下需求了，其它工程化需要的husky配置同理。
lint-staged
如果一个项目中期才引入husky，那么我们只想对git add到暂存区的文件进行git hook的脚本触发，那么可以借助lint-staged来实现。