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

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

2018/06/11 · JavaScript
· 格式化

原文出处:
Edwin   

一、问题痛点

  • 在团队的花色开发过程中,代码维护所占的光阴比重往往超越新职能的支付。由此编写符合公司编码规范的代码是重点的,这样做不仅可以很大程度地避免基本语法错误,也保证了代码的可读性。
  • 对此代码版本管理类别(svn 和
    git或者其他),代码格式不同等带来的题材是严重的,在代码一致的景象下,因为格式不同,触发了本子管理序列标记为
    diff,导致不可以检查代码和校验。

唯独急需领悟的是,开发规范不仅仅包含代码格式规范,还有好多情节,这里只是独自表金朝码格式化规范而已。

(一)关于代码格式规范问题

代码格式规范的正儿八经可以参照各大主流公司和社区,以下都是有的常用主流规范:

参考别人的规范,制定切合自己团队选择的专业,太过复杂的科班实施起来太难为,太过简单的正规化不如没有正式。

不曾断然的正统,唯有顺应的规范!

(二)关于为何要用 eslint 和 prettier问题

  • 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
的平整编写,也会回落过多手动修改样式的地方,格式化后的代码会愈发雅观,耐看。

三、具体操作

由于网上著作证实的相比混乱,这里根本是为了梳理整个工艺流程和思路。

大纲

  1. 联合团队拔取的开发工具(webstorm,ide 编辑器)
  2. 安装 eslint 和 prettier (node 模块)
  3. 设置 eslint 和 prettier ( ide 编辑器的插件)
  4. 配置 eslint 和 prettier
  5. 配置 editorconfig (可选)
  6. 严刻督查,遵照流程检查和格式化代码,遵照正规和要求开展代码提交。

此处多了一步是设置 eslint 和 prettier ( ide
编辑器的插件),重要就是利用 ide
编辑器做代码格式错误指示和代码格式处理,那些操作也可以拔取 webpack
打包的时候来做,也得以运用 gulp 或者 npm
来做,但这边借助编辑器会更有益于。

(一)统一团队利用的开发工具(webstorm,ide 编辑器)

开发工具能够做过多事物,是支付代码的利器,然则不同的开发工具会有两样的代码提醒,代码格式化,代码检查的编制,这样的差距化会对团队代码规范(开发和自我批评)带来诸多题目,所以需要统一。

当然,假使个人不愿意更换自己用惯的开发工具的话,也没提到,只要可以做到跟团队的开支规范保持一致也是足以的,但个体觉得,这样难度相比大,毕竟开发工具和团伙的支付规范不那么容易融合。

这边只表明前端业界近来最常用的开发工具来做例子 webstorm 。

(二)安装 eslint 和 prettier (node 模块)

设置这个模块的意思在于,实际上,整个流程最基本就是那么些地点,开发工具即使协理了这2个模块,但是最后运行是必须要以那2个模块安装好才能使用的。

JavaScript

// 这里需要全局安装最着重的三个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

1
2
3
4
5
6
7
// 这里需要全局安装最主要的两个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 模块:

JavaScript

npm -g install babel-eslint eslint-plugin-html –save-dev

1
npm -g install babel-eslint eslint-plugin-html –save-dev
  • babel-eslint :
    • 些微代码是没被 eslint 辅助的(因为 babel
      也是肩负这种业务,转译不被扶助的 js
      语法),所以需要添加这些插件来维系兼容性。
    • 法定有详尽介绍:https://github.com/babel/babel-eslint
  • eslint-plugin-html:
    • 为了让eslint 可以检查.vue文件的代码。

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

更多安排形式参考:WebStorm Setup ·
Prettier

据悉官方介绍webstorm 分别有2种处理:

  1. WebStorm 2018.1 和上述的本子
  2. WebStorm 2017.3 和更早的本子

尽管用AMDliJ IDEA, PhpStorm, PyCharm, and other JetBrains IDEs,
则需要安装prettier插件和 eslint 插件,而webstorm
的话默认会帮您安装上,这也是引进 webstorm 的缘故。

1. WebStorm 2018.1 和上述的本子

合法默认已经集成了 prettier 援助,只需要配备好一个大局的 prettier
模块调用形式就足以行使了(必须配备)。图片 1

图片 2

快速键是:Alt-Shift-Cmd-P on macOS or Alt-Shift-Ctrl-P on Windows and Linux

氪金王的益处,升级快,匡助快,免破解,省心省时不省钱!

2. WebStorm 2017.3 和更早的本子

那么些版本有2种状态:

  • ①是eslint 模式,使用 eslint-plugin-prettier 插件和启用eslint
    插件配合,这里一定于采用 eslint 模块来驱动 prettier
    模块,然后中间驱动则是靠eslint-plugin-prettier

第一启用 eslint,并且配备 eslint 模块地点,默认会自动读取当前目录的
eslint.rc 配置文件,然后需要举办 npm
安装eslint-plugin-prettier以此插件,前边再统一验证。

图片 3
图片 4

  • ②是直接使用 prettier 作为额外工具来利用。
    图片 5图片 6图片 7
    图片 8下边两种艺术的默认快捷键都是Cmd/Ctrl-Shift-A(在
    mac 下是comm+shift+A),觉得不舒服,按需修改急速键即可。

(三) 配置 eslint 插件和 prettier插件

1. eslint 的配置

eslint 的反省规则是因此配备文件.eslintrc 实现的,然而各家有各家的
eslint 配置文件GitHub – AlloyTeam/eslint-config-alloy: AlloyTeam ESLint
规则

图片 9图片 10

详尽参考网址:

但是这里不纠结用哪种 eslint
的安排,具体看档次和团组织,这里只是表明需要做 eslint
的布局,并且需要做一些表明:

.eslintrc 配置文件需要加上修改地点,重如果为着
prettier插件和eslint-config-prettier
插件和eslint-plugin-prettier插件使用的:

JavaScript

// 因为运用了 eslint 和 prettier,所以要添加她们 extends: [
‘eslint:recommended’, ‘plugin:prettier/recommended’], // required to
lint *.vue files 使用 html参数 plugins: [‘html’, ‘prettier’], //
rules 规则就依据各家写法。

1
2
3
4
5
6
7
// 因为使用了 eslint 和 prettier,所以要加上他们
extends: [ ‘eslint:recommended’, ‘plugin:prettier/recommended’],
 
// required to lint *.vue files 使用 html参数
plugins: [‘html’, ‘prettier’],
 
// rules 规则就按照各家写法。

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

2. prettier的配置

prettier 的自我批评规则是因此安排文件.prettierrc
实现的,不过貌似的话,只需要配备少部分平整即可:

JavaScript

{ “printWidth”: 100, “singleQuote”: true, “semi”: false }

1
2
3
4
5
{
  "printWidth": 100,
  "singleQuote": true,
  "semi": false
}

有可能会师世的景色是,prettier 格式化后,全体加了分店,不过 eslint
又要去掉分号,那么就会再也了,这里可以简单地设置 prettier 的分店设置跟
eslint
保持一致,其他如此类推,但只适用在多少个相比较特其它位置,可以参照官方文档。官方有详尽的介绍:Configuration
File · Prettier

(四) 配置 editorconfig

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

对此我个人的接头就是,editorconfig可以援救开发工具在机关格式化或者机关排版或者录入排版的时候举行代码格式化,可是只好协理相比简单的条条框框,可是也减轻了一局部代码格式化的下压力和基金,所以有比尚未好,而且最好要有。

JavaScript

// 放在项目根目录的.editorconfig文件 root = true [*] charset = utf-8
indent_style = space indent_size = 2 end_of_line = lf
insert_final_newline = true trim_trailing_whitespace = true

1
2
3
4
5
6
7
8
9
10
// 放在项目根目录的.editorconfig文件
root = true
 
[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

详尽参考:

(五) 严苛监督,遵照流程检查和格式化代码,按照专业和要求举办代码提交。

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

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

  1. 行使eslint 并且尝试自动修复所有题目(eslint 有 autofix
    指示,能够拓展—fix 修复,遵照 .eslintrc 配置文件来展开修补)。
  2. 应用 prettier 格式化所有代码。
  3. 差距性修复代码,因为微微格式或者其他题材造成出错而被前两部过滤之后还余下的。(通常前面两步基本缓解了独具题目了)
  4. 把特出的格式化后的代码提交到版本库。

参照文档:

图片 11

相关文章