问题总结

项目规范可以提高代码编程的效率 专注代码的编写而不是代码的格式，统一开发规范就成了关键问题。ESLint + Prettier (+ editorconfig + husky + commitlint)可以在一定程度上实现代码层面的自动化，至少可以完成团队层面的代码规范统一（ 但是在实际的开发中，我们会遇到一些问题，将常见的问题进行总结

针对代码整体检查可以分为四个阶段：

• 编码时检查：编写代码时检查，通常表现为由 IDE 自动实时检查并进行代码提示
• 编码后检查：编写代码后检查，通常表现为手动调用检查脚本 / 工具进行代码的检查或者代码保存后由 IDE 自动检查当前文件。
• 构建前检查：构建执行前检查，通常表现为将代码检查作为构建任务的一个前置切面，构建时自动触发代码检查。见的前端构建工具如 webpack、gulp 和 Grunt 等，可以通过配置将代码检查任务添加为构建流程的一部分。例如，使用 webpack 可以通过 eslint-loader 在构建前运行 ESLint 检查
• 提交前检查：git commit 前检查，通常表现为将代码检查作为 git commit 的一个 hooks 任务，代码提交前自动触发代码检查。

编码时和编码后其实有时候可以看作一体，当你使用了类似vscode 这类工具编码，并安装了'eslint' 这类插件通过配置便可以在编写时候今天错误提示，当然如果你这些都没有做就是需要编码后运行'eslint' 检查脚本的指令帮助你发现代码错误'构建前检查',表现在现在用的 打包工具gulp 以及 webpack 配合

有了 ESLint 为什么还要使用 Prettier ​

'ESLint' 主要解决了两类问题，代码质量和风格问题这两个问题，虽然 ESLint 中代码风格检查和 'Prettier'功能重叠， "ESLint 中并非所有的格式化规则都有自动修复功能。有些格式化规则只会检测代码的格式问题，并提供警告或错误，但不会自动修复这些问题。此希望有一套自动化工具，帮我们检测代码是否规范，如果不规范，则自动能够帮我们按照既定规范格式化 这就是 prettier

"ESLint" 和 "Prettier" 是两个不同的工具，尽管它们都与代码风格和格式化相关，但它们有不同的目的和功能。

1. "ESLint" 是一个强大的静态代码分析工具，用于检查代码中的潜在问题、错误和不一致之处。它可以帮助开发者遵循一致的编码规范和最佳实践。"ESLint" 提供了丰富的规则集，可以检查 JavaScript 和 TypeScript 代码中的语法错误、变量使用、代码风格等方面。

2. "Prettier" 是一个代码格式化工具，专注于代码的排版和格式，旨在提供统一、一致的代码样式。它可以自动调整代码的缩进、空格、换行符等，使代码具有统一的外观。"Prettier" 不仅支持 JavaScript 和 TypeScript，还支持其他语言如 CSS、Markdown 等。

为什么会同时使用 "Prettier" 和 "ESLint" 呢？

• "Prettier" 的目标是提供一种统一的、无争议的代码格式，而不仅仅是修复错误。它可以消除开发团队成员之间关于代码样式的争议，提高代码的可读性和可维护性。
• 尽管 "ESLint" 也提供一些格式相关的规则，但它的主要重点是代码质量和错误检测。并非所有 "ESLint" 的规则都提供了自动修复功能，有些规则只是用于警告开发者潜在的问题。
• "Prettier" 可以与 "ESLint" 配合使用，通过使用插件或配置文件，将其集成到开发工作流中。这样可以在保持代码质量的同时，确保代码的一致性和格式化。

总而言之，"Prettier" 和 "ESLint" 是两个不同但互补的工具，它们在代码风格和格式化方面有不同的优势和功能，通过同时使用它们可以提高代码质量和可维护性。 因此整体的代码风格规范化还得交给 Prettier。

当 eslint 和 prettier 一起搭配的时候 ​

ESLint 之类的 Linters 对于代码格式化的能力是有限的，不如 Prettier 那么专业因此对代码风格规则上的约束工具二者必然就会出现冲突解决方法: 安装这两个插件

npm i eslint-plugin-prettier eslint-config-prettier -D

• eslint-config-prettier- 和一般的eslint-config-xxx不同，它不是用来共享 ESlint 配置的，而是用来关闭 ESLint 的样式规则的，避免 ESLint 的样式规则和 Prettier 冲突。使用该配置后，对代码进行prettier和eslint就不会冲突了。但要注意一定要把它放在extends中最后的位置，避免后续的配置又把相关规则打开了。

• eslint-plugin-prettier- 将 Prettier 集成到 ESlint 工作流中，不需要再单独使用prettier命令。将 Prettier 发现的代码样式问题当作一条 ESLint 规则，在运行eslint检查后显示出来，也同样可以在--fix时修复。需要配合eslint-config-prettier使用。个人使用了一下基本 OK，但是由于 Prettier 不像 ESLint 那样是单独的一条条规则，因此错误的显示不是很友好。

使用 'eslint-config-prettier'来关掉 (disable) 所有和 Prettier 冲突的 ESLint 的配置在 .eslintrc 里面将 prettier 设为最后一个 extends

// .eslintrc
    {
        "extends": ["prettier"] // prettier 一定要是最后一个，才能确保覆盖
    }

使用插件'eslint-plugin-prettier',之前介绍过'plugin' 是扩展的规则，现在扩展'prettier '

// .eslintrc
    {
        "plugins": ["prettier"],
        "rules": {
            "prettier/prettier": "error"
        }
    }

上面两步的分别解决了 关闭和eslint 的冲突，适配prettier 的检查规则赋予eslint ，正常情况下我们是要将上面两个步骤和在一起就是下面的配置，也是官方的推荐配置

// .eslintrc
    {
      "extends": ["plugin:prettier/recommended"]
    }

Prettier 还需要 EditorConfig ​

EditorConfig 解决了编辑器配置层面的编码风格一致性问题。作用于预览和输入阶段，Prettier 在保存和提交阶段重新组织代码，Prettier 会成为代码形态的最终决定者

EditorConfig 覆盖所有类型的文件，可以采用 EditorConfig 管理相交属性，其他属性则由 Prettier 控制。

EditorConfig 使不同编辑器可以保持同样的配置。因此，我们得以无需在每次编写新代码时，再依靠 Prettier 来按照团队约定格式化一遍（译注：出现保存时格式化突然改变的情况）。当然这需要在你的 IDE 上安装了必要的 EditorConfig 插件或扩展。

并且关于代码风格的部分并未涉及，比如是否「需要在语句末尾添加分号」，「字符串使用单引号还是双引号包裹」，「多行对象的书写规范」等等。这些都是 Prettier 的工作范畴，而不是 EditorConfig 的。