代码评审的乌龙
分享一个有趣儿的事儿，供大家一乐。前几天，我们组代码评审，评审到我的时候，领导打开编译器，发现满屏的Eslint警告：
领导问我：这里为什么还有那么多 ESLint 报错？你没检查过吗？
我很坚定的回答：检查了啊，我格式啥的都是用prettirer一个文件一个文件ctrl + s 保存的，而且我代码本地也没爆红哇。然后，我自信的甩出屏幕截图：
领导说：你是不是vscode没安装Esint插件或者打开它？
我说是的，然后安装了Eslint
结果很尴尬，因为我没装Eslint插件，所以格式错误没显示出来。
于是，我赶忙解释，我一会儿下去再检查下，每个页面都用prettirer格式化一下！
领导又说，你为啥不用Eslint的fix功能吗？这么麻烦干啥？
由于我不知道Eslint的fix功能咋用，我想到没想，直接说：我觉得太麻烦了，我就喜欢用prettirer格式化，简单方便！
说完，领导同事们都笑了！我立马红温，意识到自己可能说错话了。后来，我搜了一下Eslint的fix功能，立马用脚趾在办公室抠出三室一厅。
哎，没文化真尴尬！我还是好好学习下Eslint的fix功能吧！
eslint --fix 的作用
ESLint 是一个强大的 JavaScript 和 TypeScript 代码检查工具，它可以帮助开发者保持代码的统一性和质量。
eslint --fix 是 ESLint 提供的自动修复功能，可以帮助我们快速修复符合规则的格式化错误。
比如，当我执行eslint --fix的修复功能时，代码中所有的格式相关问题都被自动修复了。
如何使用 eslint --fix
使用 eslint --fix 非常简单，只需要在命令行中执行该命令即可。
安装 ESLint
一般来说，我们的项目中已经都已经安装了 ESLint，脚手架一般都做好内置了。
npm install eslint --save-dev
eslint --fix
在项目根目录的控制台下，运行以下命令来修复代码：
npx eslint --fix .
这条命令会在当前目录下递归地查找所有文件并尝试修复符合规则的格式化问题。
我们也可以指定特定的文件或目录来修复，这样速度会更快！
npx eslint --fix src/**/*.js
此命令将只修复 src 目录下的所有 JavaScript 文件。
我们也可以使用 --ext 选项来指定文件扩展名，修复不同类型的文件：
npx eslint --fix --ext .js,.jsx,.ts,.tsx .
这条命令会修复项目中所有 JavaScript 和 TypeScript 文件。
eslint --fix 的修复范围
修复的文件格式
eslint --fix 支持对多种文件格式进行修复，具体支持的文件格式取决于 ESLint 配置文件中的 overrides 或插件配置。
- JavaScript 文件：
.js - TypeScript 文件：
.ts,.tsx - JSON 文件：
.json（如果启用了相应规则） - Vue 文件：
.vue（使用 Vue 插件时） - Markdown 文件：
.md（使用 markdown 插件时）
如果我们的项目使用脚手架创建，一般来说Vue 插件是内置的，我们不用额外配置就能针对vue项目进行识别。
自动修复的规则
不是所有 ESLint 规则都支持自动修复。eslint --fix 只会自动修复那些具备修复能力的规则。对于可以自动修复的规则，ESLint 会根据文件中的问题来进行修复。
支持修复的规则示例：
indent：强制一致的缩进。quotes：强制使用单引号或双引号。semi：强制使用分号。no-trailing-spaces：禁止行尾空格。space-infix-ops：运算符两侧是否有空格。brace-style：大括号风格。
不支持修复的规则示例：
no-unused-vars：禁止未使用的变量。no-undef：禁止未定义的变量。consistent-return：确保函数的一致性返回。
配置文件和规则
除了自动修复，我们也可以自己配置 ESLint 配置来指定eslint --fix修复。
配置示例：
// eslint的配置文件
{
"extends": ["eslint:recommended"],
"rules": {
"semi": ["error", "always"],
"quotes": ["error", "single"],
"indent": ["error", 2],
"no-trailing-spaces": ["error"]
}
}
在上述配置中，eslint --fix 会修复分号、引号、缩进和行尾空格的问题。
eslint --fix 配置到 package.json 的 scripts 中
每次在控制台根目录执行下面的修复命令是非常痛苦的！
npx eslint --fix --ext .js,.jsx,.ts,.tsx .
指令太长，根本记不住啊！所以我们可以将eslint --fix配置到package.json 的 scripts 中，像使用npm run dev一样方便的执行eslint的fix功能！
我们可以在 package.json 文件的 scripts 部分添加一个自定义的命令来运行 eslint --fix。
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"lint": "eslint .",
"lint:fix": "eslint --fix ."
},
"devDependencies": {
"eslint": "^8.0.0"
}
}
在上面的示例中，我们配置了两个脚本命令：
lint：运行 ESLint 检查整个项目的代码，但不进行修复。lint:fix：运行 ESLint 并自动修复项目中符合规则的格式问题。
运行 npm run lint:fix 后，ESLint 会检查代码中的格式问题，并自动修复符合自动修复条件的规则。修复完成后，ESLint 会输出日志，列出已修复的文件和修复的规则。
eslint --fix的额外参数有哪些
eslint --fix 命令支持多种额外的参数，这些参数能够帮助我们更精确地控制 ESLint 检查和修复的行为。下面是一些常见的额外参数及其用途：
--fix-type
--fix-type 允许你指定自动修复的类型。它可以帮助你控制修复的范围，避免执行不必要的修复。
可选值：
problem：只修复报告中的问题（默认行为）。suggestion：修复建议性的更改（如优化代码的建议）。layout：修复布局相关的问题，如格式化、缩进等。all：修复所有类型的问题，包括问题、建议和布局。
示例：
如果我们只想修复布局问题，可以使用以下命令：
eslint --fix --fix-type layout
这样只会修复格式化相关的问题，如多余的空格、行尾空格等。
--max-warnings
--max-warnings 设置允许的最大警告数量。默认情况下，ESLint 会返回所有警告。如果超出这个数量，eslint 会返回一个非零退出代码。
示例：
如果我们希望 ESLint 只允许最多 5 个警告，超出后则标记为失败，可以使用：
eslint --fix --max-warnings 5
此时，如果警告超过 5 个，命令会返回一个非零退出状态，通常会在 CI/CD 系统中触发失败。
--ignore-path
--ignore-path 允许我们指定一个文件，ESLint 会根据该文件中的规则来忽略某些文件或目录。这可以让我们在大项目中根据需要忽略特定的文件或目录，而不必在 .eslintignore 文件中配置。
示例：
假设我们有一个名为 my-ignore-file.txt 的文件，里面列出了要忽略的路径，可以使用以下命令：
eslint --fix --ignore-path my-ignore-file.txt
--ignore-pattern
--ignore-pattern 允许我们直接在命令行中指定要忽略的文件模式。
示例：
如果想忽略 node_modules 和 dist 目录，可以使用以下命令：
eslint --fix --ignore-pattern node_modules/* --ignore-pattern dist/*
此命令会忽略这两个目录中的所有文件。
--quiet
--quiet 让 ESLint 只报告错误，而不报告警告。
--cache
--cache 使 ESLint 在运行时生成一个缓存文件，记录哪些文件发生了变化，从而只对变化的文件进行检查和修复。这可以显著加快大项目的 ESLint 执行速度。
eslint --fix --cache
默认情况下，缓存文件会保存在 .eslintcache 文件中。如果你希望更改缓存文件的路径，可以使用 --cache-location 参数。
--no-ignore
默认情况下，ESLint 会自动忽略通过 .eslintignore 文件或 --ignore-pattern 指定的文件和目录
使用 --no-ignore 忽略忽略规则并检查所有文件：
eslint --fix --no-ignore
总结
通过我的尴尬经历，希望大家能意识到：工具的正确使用可以大大提升效率，减少出错几率。ESLint 是一个强大的工具，eslint --fix 功能尤为实用——它可以自动修复格式和部分常见问题，让代码变得干净整洁，省去手动处理的麻烦。
通过配置 eslint --fix 到脚本中，比如 npm run lint:fix，我们可以进一步优化开发流程。加上参数如 --fix-type、--cache 等，更能根据项目需求精准控制修复范围。
学会使用 eslint --fix，不仅让代码更规范，还避免在评审中闹出“抠脚”级别的乌龙！所以，少些尴尬，多些学习吧！
