梳理前端开发使用eslint-prettier检查和格式化代码

梳理前端开发使用eslint-prettier检查和格式化代码

问题痛点

• 在团队的项目开发过程中，代码维护所占的时间比重往往大于新功能的开发。因此编写符合团队编码规范的代码是至关重要的，这样做不仅可以很大程度地避免基本语法错误，也保证了代码的可读性。
• 对于代码版本管理系统（svn 和 git或者其他），代码格式不一致带来的问题是严重的，在代码一致的情况下，因为格式不同，触发了版本管理系统标记为 diff，导致无法检查代码和校验。

但是需要知道的是，开发规范不仅仅包含代码格式规范，还有很多内容，这里只是单独说明代码格式化规范而已。

解决办法原理

1. 使用 eslint 检查代码
2. 使用 prettier 格式化代码（prettier是 eslint —fix 的加强版）
3. 使用 editorconfig 协助兼容开发工具的代码格式化

文章大纲：

鉴于网上文章说明的比较混乱，这里主要是为了梳理整个流程和思路，然后对比网上的文章重新理解和学习 eslint 和 prettier 和代码检查和代码格式化。

1. 统一团队使用的开发工具（ide 编辑器）

   1. webstorm（或者JetBrains: Developer Tools for Professionals and Teams系列开发软件）
   2. vscode （Visual Studio Code - Code Editing. Redefined）
   3. 安装不同ide 编辑器的对应的 eslint 插件和 prettier 插件
2. 安装 eslint 和 prettier （node 模块）

3. 配置 eslint 和 prettier

   1. 配置团队使用的 rules
4. 配置 editorconfig
5. 严格督查，按照流程检查和格式化代码，按照规范和要求进行代码提交。

第一、统一团队使用的开发工具（ide 编辑器）

开发工具可以做很多东西，是开发代码的利器，但是不同的开发工具会有不同的代码提示，代码格式化，代码检查的机制，这样的差异化会对团队代码规范（开发和检查）带来很多问题，所以需要统一。

当然，如果个人不愿意更换自己用惯的开发工具的话，也没关系，只要能够做到跟团队的开发规范保持一致也是可以的，但个人觉得，这样难度比较大，毕竟开发工具和团队的开发规范不那么容易融合。

这里只说明前端业界目前最常用的两种开发工具来做例子，分别是 webstorm 和 vscode。

~webstorm 或者 vscode 分别安装好之后需要安装eslint 插件和 prettier 插件。~

安装webstorm 的eslint 插件和 prettier 插件并启用插件

更多配置方式参考：WebStorm Setup · Prettier

根据官方介绍webstorm 分别有2种处理：

1. WebStorm 2018.1 和以上的版本
2. WebStorm 2017.3 和更早的版本

如果用IntelliJ IDEA, PhpStorm, PyCharm, and other JetBrains IDEs, 则需要安装prettier插件和 eslint 插件，而webstorm 的话默认会帮你安装上。

WebStorm 2018.1 和以上的版本

官方默认已经集成了 prettier 支持，只需要配置好一个全局的 prettier 模块调用方式就可以使用了（必须配置）。

[image:92501044-1ADD-41CB-BD0C-A08BF017856E-2833-0000064BE8D16DB1/5CC2BD82-B4E3-459A-A96A-8652870832E8.png]

快捷键是：Alt-Shift-Cmd-P on macOS or Alt-Shift-Ctrl-P on Windows and Linux

氪金王的好处，升级快，支持快，免破解，省心省力不省钱！

WebStorm 2017.3 和更早的版本

这个版本有2种情况：

• ①是eslint 模式，使用 eslint-plugin-prettier 插件和启用eslint 插件配合，这里相当于使用 eslint 模块来驱动 prettier 模块，然后中间驱动则是靠eslint-plugin-prettier。

首先启用 eslint，并且配置 eslint 模块位置，默认会自动读取当前目录的 eslint.rc 配置文件，然后需要进行 npm 安装eslint-plugin-prettier这个插件，后面再统一说明。
[image:45E71C29-2933-4178-8B54-1624D7BDE6ED-2833-0000080224C7A18F/F82912F6-0F7C-4D89-9A2C-EA1C8CF41469.png]

• ②是直接使用 prettier 作为额外工具来使用。

[image:EB38EB6E-FB83-4C2B-B3FE-005FB45D1B81-2833-00000778833EC282/223C3C42-AE59-4501-9119-E44ACB0C38EE.png]

[image:BE8CDA11-63C4-4661-93BB-146299063BD9-2833-0000077989F51D06/2DE327F9-2274-448E-816A-D53057B4FB6F.png]

---

上面两种方式的默认快捷键都是Cmd/Ctrl-Shift-A（在 mac 下是 comm+shift+A），觉得不舒服，按需修改快捷键即可。

[image:BD12F495-B168-485D-9E1B-CA30E07D4917-2833-000007DCC3947E10/36E1EB4E-769A-456D-B7F4-C1C61FD76086.png]

安装 vscode的eslint 插件和 prettier 插件

打开 VSCode 扩展面板并搜索 ESLint 插件 和 prettier 插件，然后点击安装。（prettier 插件没截图，但类似）
[image:478E5E36-1056-4C77-8D98-D009559070CB-2833-000008A49B4C4EFC/D8C1E6E5-619D-48BA-93C8-EBA1091B9FBD.png]

安装完毕之后点击 ~重新加载~ 以激活插件。

vscode 的快捷键：

1. CMD + Shift + P -> Format Document

或者

1. Select the text you want to Prettify
2. CMD + Shift + P -> Format Selection

官网有详细介绍：GitHub - prettier/prettier-vscode: Visual Studio Code extension for Prettier

第二、安装 eslint 和 prettier （node 模块）

安装这个模块的意义在于，实际上，整个流程最核心就是这个地方，开发工具虽然支持了这2个模块，但是最终运行是必须要以这2个模块安装好才能使用的。

这是 node 的模块，用 nam 或者 yarn 的方式安装，以下是以 npm 安装为例。

nam -g install eslint eslint-plugin-prettier eslint-config-prettier babel-eslint prettier eslint-plugin-html --save-dev

• 使用-g是因为这些都是全局使用的模块（尤其是 eslint 和 prettier），不用每次重复安装，而且也容易被开发工具找到，当然也可以选择不用-g，自行处理模块位置。
• eslint 和prettier 不说。

• eslint-plugin-prettier 是之前说过，这里重新说明一下：

  • 这个是在低版本的 webstorm 里面使用 prettier 时候要求安装的插件。
  • eslint 要跟 prettier 配合，需要有这个插件来做过渡（或者叫驱动），低版本的 webstorm 用到这个插件也是这个意思。

• eslint-config-prettier ：

  • 这个插件是如果eslint的规则和prettier的规则发生冲突的时候（主要是不必要的冲突），例如eslint 限制了必须单引号，prettier也限制了必须单引号，那么如果用 eslint 驱动 prettier 来做代码检查的话，就会提示2种报错，虽然他们都指向同一种代码错误，这个时候就会由这个插件来关闭掉额外的报错。
  • 但如果是eslint 只负责检测代码，prettier 只负责格式化代码，那么他们之间互不干扰，也就是说，也是可以不安装这个插件的，但是因为团队的人员的差异性（即使同一个开发工具也有版本差异，也有使用 prettier 和 eslint 的差异），可能有存在各种情况，所以最好还是安装上这个插件。
  • 官方有详细介绍：GitHub - prettier/eslint-config-prettier: Turns off all rules that are unnecessary or might conflict with Prettier.

• babel-eslint ：

  • 有些代码是没被 eslint 支持的（因为 babel 也是负责这种事情，转译不被支持的 js 语法），所以需要加上这个插件来保持兼容性。
  • 官方有详细介绍：https://github.com/babel/babe...

• eslint-plugin-html：

  • 问了让eslint 可以检查.vue文件的代码。

第三、配置 eslint 插件和 prettier插件

eslint 的配置

eslint 的检查规则是通过配置文件.eslintrc 实现的，但是各家有各家的 eslint 配置文件GitHub - AlloyTeam/eslint-config-alloy: AlloyTeam ESLint 规则：

[image:183FFECA-1463-4847-995C-7968ACB07CDE-2833-00000FC1A80835A6/A9CB9340-A21E-42C9-ADF2-76B4351FA7D2.png]

详细参考网址：

• AlloyTeam ESLint 规则
• 摆脱令人抓狂的ESlint 语法检测配置说明 - web攻城方略 - SegmentFault 思否
• ESLint配置文件.eslintrc参数说明 · GitHub

不过这里不纠结用哪一种 eslint 的配置，具体看项目和团队，这里只是说明需要做 eslint 的配置，并且需要做一些说明：

.eslintrc 配置文件需要添加修改地方，主要是为了 prettier插件和eslint-config-prettier 插件和eslint-plugin-prettier插件使用的：

  // 原extends: 'eslint:recommended',
  extends: ['prettier', 'eslint:recommended'],
  // required to lint *.vue files 使用 html参数
  plugins: ['html', 'prettier'],

在 webstorm 下：

• 在项目根目录.eslintrc作为配置文件。

在 vscode 下：

• 在项目根目录.eslintrc作为配置文件。
• 然后依次点击 文件 > 首选项 > 设置 打开 vscode 配置文件，然后配置指定使用哪个 eslintrc 文件作为 vscode 的配置文件。

[image:21128230-D925-4913-9B21-68C26C371CB6-2833-000010E826578238/162A9A99-B87A-469B-82FD-A570A7352937.png]

[image:BB2B7C90-692F-4731-93DC-D48E5E5F63FD-2833-000010E936A05A4C/6566C009-8837-4BA7-BC56-4F8EEF8AA928.png]

"eslint.options": {
    "configFile": "E:/git/github/styleguide/eslint/.eslintrc.js"
},

• 在 VSCode 中，默认 ESLint 并不能识别 .vue、.ts 或 .tsx 文件，需要在「文件 => 首选项 => 设置」里做如下配置：

{
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        "html",
        "vue",
        "typescript",
        "typescriptreact"
    ]
}

详细参考：使用 VSCode + ESLint 实践前端编码规范 - decoder - SegmentFault 思否

prettier的配置

prettier 的检查规则是通过配置文件.prettierrc 实现的，不过一般来说，只需要配置少部分规则即可：

{
  "printWidth": 100,
  "singleQuote": true, // 这个地方需要跟 eslint 的规则保持一致
  "semi": false // 这个地方需要跟 eslint 的规则保持一致
}

官方有详细的介绍：Configuration File · Prettier

这个配置在 webstorm 下和 vscode 都一样。

第四、配置 editorconfig

• EditorConfig可以帮助开发者在不同的编辑器和IDE之间定义和维护一致的代码风格。
• EditorConfig包含一个用于定义代码格式的文件和一批编辑器插件，这些插件可以让编辑器读取配置文件并依此格式化代码。

对此我个人的理解就是，editorconfig可以协助开发工具在自动格式化或者自动排版或者录入排版的时候进行代码格式化，但是只能支持比较简单的规则，不过也减轻了一部分代码格式化的压力和成本，所以有比没有好，而且最好要有。

// 放在项目根目录的.editorconfig文件
root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

详细参考：

• 【译】EditorConfig介绍 | AlloyTeam
• EditorConfig

第五、严格督查，按照流程检查和格式化代码，按照规范和要求进行代码提交。

需要明确一点，代码格式化需要由上而下执行，如果没有强制性压力督促，那么是对抗不了人类的惰性的。

整个代码检查和格式化流程应该规范为如下步骤：

1. 使用eslint 并且尝试自动修复所有问题（eslint 有 autofix 提示，可以进行—fix 修复，按照 .eslintrc 配置文件来进行修复）。
2. 使用 prettier 格式化所有代码。
3. 差异性修复代码，因为有些格式或者其他问题导致出错而被前两部过滤之后还剩余的。（通常前面两步基本解决了所有问题了）
4. 把精美的格式化后的代码提交到版本库。

参考文档：

• 如何花30分钟解决 eslint 产生的各种错误 | Tomyail的记忆现场

---

原文转载：梳理前端开发使用 eslint+prettier 检查和格式化代码 | 线上猛如虎，线下怂如鼠（WhyNotBetter）