更新版-梳理前端开发使用eslint和prettier来检查和格式化代码问题

摘要：整个代码检查和格式化流程应该规范为如下步骤使用并且尝试自动修复所有问题有提示，可以进行修复，按照配置文件来进行修复。参考文档如何花分钟解决产生的各种错误的记忆现场本文转载自我的更新版梳理前端开发使用和来检查和格式化代码问题

更新版，之前的版本可以看这里：梳理前端开发使用eslint和prettier来检查和格式化代码问题

在团队的项目开发过程中，代码维护所占的时间比重往往大于新功能的开发。因此编写符合团队编码规范的代码是至关重要的，这样做不仅可以很大程度地避免基本语法错误，也保证了代码的可读性。

对于代码版本管理系统（svn 和 git或者其他），代码格式不一致带来的问题是严重的，在代码一致的情况下，因为格式不同，触发了版本管理系统标记为 diff，导致无法检查代码和校验。

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

代码格式规范的标准可以参考各大主流公司和社区，以下都是一些常用主流规范：

前端开发规范之命名规范、html规范、css规范、js规范 - 腾讯Web前端 IMWeb 团队社区 | blog | 团队博客 腾讯的

编写「可读」代码的实践 | Taobao FED | 淘宝前端团队 淘宝的

GitHub - airbnb/javascript: JavaScript Style Guide airbnb 的

https://google.github.io/styl... google 的

https://github.com/pablohpsil... vue 的

参考别人的规范，制定适合自己团队使用的规范，太过复杂的规范执行起来太麻烦，太过简单的规范不如没有规范。
没有绝对的规范，只有适合的规范！

prettier 主要是为了格式化代码，而在没有 prettier 之前，是用 eslint —fix和 编辑器自带代码格式来进行代码格式化的。

缺点：每种编辑器会有不一样的代码格式，而且配置会比较麻烦。

prettier 已经逐渐成为业界主流的代码风格格式化工具。

减轻 eslint 等工具的校验规则，因为将代码样式校验交给了 prettier，所以可以将代码校验的规则更准确地应用到代码真正的规范上面。

eslint 是主要还是负责代码规则校验，prettier 只调整代码风格，代码样式，eslint 才是真正检查代码是否符合规范的工具。

所以两者是需要配合使用的。

旧有的解决办法是：

使用 editorconfig 协助兼容开发工具的代码格式化。

使用 eslint 检查代码

使用 eslint —fix来修复不符合 eslint 规则的代码，它会自动根据设置的规则来改变代码（它会包含代码样式的规则，但是 eslint 的样式规则并不太准确）。

手动修改剩下的有问题的地方，或者有些地方很难用规则来判断的时候，就需要手动修改。

新的解决办法是：

使用 editorconfig 协助兼容开发工具的代码格式化。

使用 eslint 检查代码。

使用 prettier 格式化代码。（可以理解为prettier是 eslint —fix 的加强版，用 prettier 来代替 eslint-fix）

手动修改剩下的有问题的地方，或者有些地方很难用规则来判断的时候，就需要手动修改。

咋一看，其实没啥区别，甚至可能发现新解决办法会更加麻烦了一些，其实步骤上确实如此，但是真正操作上，会减轻 eslint 的规则编写，也会减少很多手动修改样式的地方，格式化后的代码会更加美观，耐看。

鉴于网上文章说明的比较混乱，这里主要是为了梳理整个流程和思路。

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

安装 eslint 和 prettier （node 模块）

安装 eslint 和 prettier （ ide 编辑器的插件）

配置 eslint 和 prettier

配置 editorconfig （可选）

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

这里多了一步是安装 eslint 和 prettier （ ide 编辑器的插件），主要就是利用 ide 编辑器做代码格式错误提醒和代码格式处理，这个操作也可以使用 webpack 打包的时候来做，也可以使用 gulp 或者 npm 来做，但这里借助编辑器会更方便。

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

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

这里只说明前端业界目前最常用的开发工具来做例子 webstorm 。

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

// 这里需要全局安装最主要的两个node 模块，主要是要让 ide 编辑器能够读取全局环境来调用这2个模块
npm install eslint prettier -g --save-dev

// 这个是为了 eslint 跟 prettier 可以联合使用
npm install --save-dev eslint-plugin-prettier
// 这个是为了让 eslint 跟 prettier 兼容，关闭 prettier 跟 eslint 冲突的rules
npm install --save-dev eslint-config-prettier

补充备注：

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.

模块参考信息：Integrating with ESLint · Prettier

以下顺便说一下其他我们常用到的eslint 模块：

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

babel-eslint ：

有些代码是没被 eslint 支持的（因为 babel 也是负责这种事情，转译不被支持的 js 语法），所以需要加上这个插件来保持兼容性。

官方有详细介绍：https://github.com/babel/babe...

eslint-plugin-html：

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

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

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

WebStorm 2018.1 和以上的版本

WebStorm 2017.3 和更早的版本

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

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

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

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

这个版本有2种情况：

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

首先启用 eslint，并且配置 eslint 模块位置，默认会自动读取当前目录的 eslint.rc 配置文件，然后需要进行 npm 安装eslint-plugin-prettier这个插件，后面再统一说明。

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

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

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

详细参考网址：

AlloyTeam ESLint 规则

摆脱令人抓狂的ESlint 语法检测配置说明 - web攻城方略 - SegmentFault 思否

ESLint配置文件.eslintrc参数说明 · GitHub

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

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

// 因为使用了 eslint 和 prettier，所以要加上他们
extends: [ "eslint:recommended", "plugin:prettier/recommended"],

// required to lint *.vue files 使用 html参数
plugins: ["html", "prettier"],

// rules 规则就按照各家写法。

在 webstorm 下，在项目根目录.eslintrc作为配置文件。

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

{
  "printWidth": 100,
  "singleQuote": true, 
  "semi": false 
}

有可能会出现的情况是，prettier 格式化后，全部加了分号，但是 eslint 又要去掉分号，那么就会重复了，这里可以简单地设置 prettier 的分号设置跟 eslint 保持一致，其他如此类推，但只适用在几个比较特别的地方，可以参考官方文档。官方有详细的介绍：Configuration File · Prettier

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

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

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

使用eslint 并且尝试自动修复所有问题（eslint 有 autofix 提示，可以进行—fix 修复，按照 .eslintrc 配置文件来进行修复）。

使用 prettier 格式化所有代码。

差异性修复代码，因为有些格式或者其他问题导致出错而被前两部过滤之后还剩余的。（通常前面两步基本解决了所有问题了）

把精美的格式化后的代码提交到版本库。

参考文档：

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

Introducing Prettier with Eslint – Michael Hsu – Medium

Efficient Code Analyzing and Formatting (for Vue.js) with ESLint and Prettier

本文转载自我的 blog：更新版 - 梳理前端开发使用 eslint 和 prettier 来检查和格式化代码问题