梳理前端开发使用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 和更早的版本

假设用IntelliJ 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

相关文章