前端语法错误引发线上问题的思考 - 前端工程化之自动化语法检测

一个不起眼的拼写错误引发的bug（例子）：

你是否注意到上图错误在哪了吗？test（tets）傻傻分不清楚！
日常搬砖时这种不经意的小问题可能随时都存在，毕竟谁都会手抖，但是怎么能避免因为这种相对不好控制的因素导致的问题呢❓

怎么避免同类问题：

1. 自己控制：每次写完代码从头到尾仔细检查一遍 （建议指数：🌟，自行检测一遍整体语法成本太高）

2. review控制：团队其他成员帮忙CodeReview （建议指数：🌟🌟🌟，当然可以就是相对效率太低了~）

3. 自动化语法检验 在研发/提交代码时自动校验 控制 （建议指数：🌟🌟🌟🌟🌟，完美! 🙌）

自动化语法检测简述以及意义：

自动化语法检测可以帮助开发者识别和修复代码中的问题。它最主要的目的是通过检测代码风格的一致性和潜在错误来提高代码的可维护性和可读性。

1. 保持代码风格一致性：不同开发者可能有不同的编码风格，但自动化语法检测可以通过预设的规则强制执行一致的风格。
2. 减少bug：自动化检测可以帮助识别潜在的bug和潜在问题，例如未使用的变量、不一致的括号使用等。
3. 提高代码可维护性：一致的代码风格可以提高代码的可读性和可维护性。

前端工程化中添加语法校验并一步步优化：

JS语法校验：

常用的JS语法校验使用ESlint处理。ESlint官网传送门
ESlint: 一个插件化的javascript代码检测工具。

安装走一波：

vue add @vue/eslint 生成eslintrc.js/json文件，随后配置对应校验规则即可校验，此处就不展开了呀。

针对开头我们举的栗子🌰，来添加ESLint校验，并运行：

命令行使用lint检查提示：

lint检查结果：

我们看，效果很明显，经过lint的检验，告诉我们代码块的问题和行数，一目了然，直接在对应处修改即可，完美！但是真的完美了吗？

工程化中单独使用ESlint缺点（校验时机）：

需要自行手动调用eslint命令去 校验 ( npm run lint )。当然配合打包工具插件（webpack，vite）可以做到边开发边监测问题，那其实工具帮我们处理了自动化的步骤，所以我们还得了解到底是怎么优化的~

🙌 工程化中第一次优化（Git Hooks）：

优化自动调用ESLint的时机：git commit
git web 给我们提供了一些钩子hooks，可以帮忙我们在和git交互前拦截并做一些操作。包含一下10种：

这里我们拿pre_commit钩子举例：pre_commit是git提交前处理的钩子函数，可以添加适合自己的自动化流程。

工程化中使用：在项目中 .git/hook/ 目录中 添加pre-commit.sh 脚本，然后在脚本中执行 eslint + 要校验的文件路径

缺点：每次都需要自行手动执行脚本，效率低，无法自行处理！

🙌 工程化中第二次优化（husky）：

Husky 是一个用于设置 Git hooks（钩子）的工具，它允许开发者在 Git 操作前或者后执行自定义的脚本。这些脚本可以用来执行各种任务，比如代码格式化、代码质量检查、单元测试等，从而帮助团队保持一致的代码质量和开发流程。

---- 说干就干，直接使用一波：
npx husky add .husky/pre-commit “npm test” 就添加了一个pre-commit的脚本，然后husky就能在commit提交时使用我们添加的hook处理逻辑了。

缺点：只是在提交时拦截并调用eslint验证所有文件，不能只针对 本次git提交 的处理。

🙌 工程化中第三次优化（lint-staged）：

Lint-staged检测 git 暂存区的文件更改:
在代码提交之前，进行代码规则检查能够确保进入git库的代码都是符合代码规则的。但是整个项目上运行lint速度会很慢，lint-staged能够让lint只检测 git 暂存区的文件，能快速处理验证。

安装后配置：

完成：至此我们的工程化里JS语法部分已经可以完美使用了。除了JS语法之后还有其他的常用的语法优化项吗？

其他可选优化项：

1. css样式校验：
   stylelint: 传送门
   stylelint跟eslint 在语法检验和使用逻辑上都是一致的，有兴趣的可以根据官网教程在项目中安装并配置使用规范即可呀。

2. 前端代码格式化工具(限制)：
   prettier: 传送门
   一个“有态度”的代码格式化工具，感兴趣可以添加使用呀。
   

项目中语言校验完整嵌入配置：