梳理前端开发使用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. 严格督查，按照流程检查和格式化代码，按照规范和要求进行代码提交。

第1、统一团队使用的开发工具（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

第2、安装 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文件的代码。

第3、配置 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 都同样。

第4、配置 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

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

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

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

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

参考文档：

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

---

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