一个中大型项目，一般由团队成员共同开发维护。但每个开发人员都有独特的代码编写风格和不同的文本编辑器。那么如何解决同一项目中有太多不同编码风格的问题？如何实现相同的编码风格，避免团队成员之间的许多警告呢？

答案就是：ESLint 搭配 Prettier！！！

ESLint

ESLint 是一个开源的 JavaScript 代码检查工具，能够发现潜在的错误、不良实践和性能问题，比如未使用的变量、潜在的类型错误或未处理的异常等。

Prettier

Prettier是一个流行的代码格式化工具，可以自动格式化代码，消除了手动调整缩进、空格、括号等格式问题的需要，使得开发者可以专注于业务逻辑而不是代码样式，提高开发效率。

ESLint 搭配 Prettier

ESLint  配置 Prettier 在项目中有以下优势和必要性：

1. 代码一致性：Lint 和 Prettier 能确保团队成员遵循统一的编码风格和格式，无论团队成员有多少，都能保持代码风格的一致性。这大大提高了代码的可读性和维护性。

2. 提高代码质量：ESLint 作为代码质量检查工具，能够发现潜在的错误、不良实践和性能问题，比如未使用的变量、潜在的类型错误或未处理的异常等，从而提升代码质量。

3. 自动化格式化：Prettier 自动格式化代码，消除了手动调整缩进、空格、括号等格式问题的需要，使得开发者可以专注于业务逻辑而不是代码样式，提高开发效率。

4. 减少代码审查工作量：由于 ESLint 和 Prettier 已经处理了很多格式和质量问题，代码审查过程可以更专注于逻辑和功能实现，而非表面的格式差异，加速代码审查流程。

5. 易于集成：两者都广泛支持各种编辑器和构建工具，如 Visual Studio Code、WebStorm、Git Hook、Webpack、Vue CLI、Create React App 等，易于在现有开发环境中集成。

6. 跨语言支持：虽然 ESLint 主要针对 JavaScript，但它也支持 TypeScript、HTML 和 JSX。而 Prettier 支持更多的编程语言，包括 CSS、SCSS、Less、Markdown 等，使得整个项目中的代码风格都能得到统一。

7. 减少团队冲突：代码风格的不一致往往是团队成员之间产生分歧的原因之一。通过统一的 ESLint 和 Prettier 配置，可以显著降低因代码风格不同而产生的代码审查意见不合，促进团队合作。

8. 持续集成/持续部署（CI/CD）友好：在 CI/CD 流程中集成 ESLint 和 Prettier，可以在代码合并前自动进行代码检查和格式化，保证主分支代码的高质量和一致性，减少因代码格式或质量问题导致的构建失败。

标准项目中的额外配置项

在项目的根目录下找到.eslintrc.js文件，打开，添加额外规则：

1.将vscode中的prettier插件禁掉，因为使用的是基于包安装的；

2.同时将设置里的 format on save 关闭；

3.为ESLint插件配置保存时自动修复

避免插件与格式化工具冲突！

{"editor.codeActionsOnSave": {"source.fixAll": "explicit"},// 关闭保存自动格式化"editor.formatOnSave": false,"editor.defaultFormatter": "esbenp.prettier-vscode"
}

/* eslint-env node */
require('@rushstack/eslint-patch/modern-module-resolution')module.exports = {root: true,extends: ['plugin:vue/vue3-essential','eslint:recommended','@vue/eslint-config-prettier/skip-formatting'],parserOptions: {ecmaVersion: 'latest'},
/*额外规则  */rules: {
/*使用的是包安装的prettier，可以将vscode中的插件禁掉*/'prettier/prettier': [ 'warn',{singleQuote: true, // 单引号semi: false, // 无分号printWidth: 80, // 每行宽度至多80字符trailingComma: 'none', // 不加对象|数组最后逗号endOfLine: 'auto' // 换行符号不限制（win mac 不一致）}],// ESLint关注于格式规范'vue/multi-word-component-names': ['warn',{ignores: ['index'] // vue组件名称多单词组成（忽略index.vue）}],'vue/no-setup-props-destructure': ['off'], // 关闭 props 解构的校验// 💡 添加未定义变量错误提示，create-vue@3.6.3 关闭，这里加上是为了支持下一个章节演示。'no-undef': 'error'}
}

基于husky的代码检查

Husky 是一个用于在 Git 提交过程中自动化代码检查和其他操作的工具，它通过 Git Hooks 实现。在 Vue 项目或任何前端项目中，Husky 可以与 ESLint、Prettier 等代码质量工具结合，确保在代码提交前符合一定的规范和质量要求。

首先要创建一个仓库，不明白的友友可以看下这篇博客：使用Git命令从本地上传到码云-CSDN博客

安装 Husky

首先，确保你的项目中已安装了 Husky。如果还没有安装，可以通过 npm 或 pnpm安装：

npm install husky --save-dev

pnpm dlx husky-init && pnpm install

配置 Husky

安装完成后，你可以在项目的根目录下创建或修改 package.json 文件，来设置 Husky 的钩子。最常用的钩子是 pre-commit 和 pre-push，分别在提交前和推送到远程仓库前触发。

例如：代码提交前做检验

修改 .husky/pre-commit文件

#npm test
pnpm lint

问题：

pnpm lint是全量检查，耗时问题、历史问题；

1.在历史代码仓库上工作的时候，一执行检测，检测报告里会出现很多报错；

2.随着代码库越来越庞大，全量检测整个项目，时间成本会越来越高；

So，一个新的方法来了！

暂存区ESLint校验

在Git工作流中，对暂存区（staging area）进行ESLint校验具有多方面的优势。

1. 仅对暂存区的文件进行校验意味着只处理那些即将被提交的代码变更，这相比检查整个项目来说大大减少了校验的时间开销，尤其是在大型项目中效果显著；
2. 因为问题在提交前就被发现并修正，避免了因小错误反复提交和修正的历史记录，使得提交历史更加清晰，便于后期追踪和回溯问题。

安装一个包：

pnpm i lint-staged -D

配置 package.json文件

{// ... 省略 ..."lint-staged": {"*.{js,ts,vue}": ["eslint --fix"]}}"scripts": {// ... 省略 ..."lint-staged": "lint-staged"}}
}

修改 .husky/pre-commit 文件

pnpm lint-staged

OK！

配置完毕，开工！