Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EditorConfig,Prettier and ESLint #2

Open
xtyi opened this issue Apr 10, 2019 · 0 comments
Open

EditorConfig,Prettier and ESLint #2

xtyi opened this issue Apr 10, 2019 · 0 comments
Labels

Comments

@xtyi
Copy link
Owner

xtyi commented Apr 10, 2019

介绍三个和代码风格有关的工具

EditorConfig

EditorConfig 很简单,它由两部分组成,一个 .editorconfig 文件,一个编辑器插件

.editorconfig 文件定义了编码风格,编辑器插件读取该文件并应用这些规则

.editorconfig 的规则不多,只有以下这些:

rules value description
root true,false,unset
charset 文件编码
end_of_line cr,crlf,lf,unset 换行符
trim_trailing_whitespace true,false,unset 去除多余的空格
insert_final_newline true,false,unset 在尾部插入一行
indent_style tab,space,unset 缩进方式
indent_size 1-8,unset 缩进大小
tab_width 1-8,unset tab 大小

一个常见的配置如下

[*]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true

[*.{js,ts}]
indent_style = space
indent_size = 2
tab_width = 2

编译器为项目设置这些规则,通常也是写入一个文件中,例如 VSCode 是将项目级别的配置放到项目根目录下的 .vscode/settings.json

{
  "editor.tabSize": 2,
  "files.insertFinalNewline": true,
  "files.trimTrailingWhitespace": true
}

那为什么还要使用 EditorConfig 呢?

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

上面是官方对于 EditorConfig 的定义,可以看出,EditorConfig 是一种统一的规范,是可以跨编程工具的(所以开源项目一般都会使用 EditorConfig)

并且使用 EditorConfig 配置只会更简单,直接创建一个 .editorconfig 文件,写点简单的规则就好了

优先级

首先,EditorConfig 的优先级 >编辑器项目级别的配置 > 编辑器全局配置

其次,对于某个特定文件来说,离它越近的 .editorconfig 文件优先级越高

EditorConfig 会从当前打开的文件所在的文件夹开始寻找 .editorconfig 文件,直到项目根目录或者找到 root=true.eidtorconfig 文件

而应用规则的时候则是从顶部到底部,后面的规则会覆盖前面的规则,因此最近的 .editorconfig 会有最高的优先级

Prettier

Prettier 是一个自以为是的代码格式化工具(An opinionated code formatter)

Opinionated

"自以为是" 是什么意思?

其实就是代码风格都帮你配置好了,你不用再配置了

你也不要讨论哪种代码风格好,如果你不爽,就去用其他的

  • You press save and code is formatted
  • No need to discuss style in code review
  • Saves you time and energy

其实这在编程中是一个很常见的概念了,最早应该是 ROR 提出的:"约定大于配置","主厨精选"

"约定大于配置" 的思想已经融入到编程的各个方面,即使是不自以为是的框架也有这个思想的体现

举例来说 Angular,Django 这些框架就是 "自以为是" 的框架

以 Angular 为例,路由,状态管理,HTTP Client,依赖注入,所有的一切都帮你选好了,你只要按照要求写代码就好了

如果你喜欢 Angular 而不喜欢这些模块呢?那没办法了,用了 Angular 你就只能用这些模块,一般情况下,这是不会发生的,因为是 "主厨精选",这些模块都是大牛写出来或者选出来的,质量都很高

而像 Vue,React,Flask,Koa 这些框架就是另外的风格

你使用 React 的话,就要自己去找路由模块,状态管理模块,CSS 方案,React 只是给了你用 JS 写 UI 的 API 而已

两者各有各的好处,Angular (opinionated framework) 更方便,React 的 CSS in JS 方案就有 50 多种呢,你会选吗?你知道怎么在 React 中用吗?用 Angular 就不用管这些,都帮你规定好了

而 React (unopinionated framework) 就更灵活一些,没有冗余的模块,社区生态也更好

使用 Prettier

最简单的方式就是安装一个 Prettier 插件

image

安装之后,VSCode 的配置项里就会多出 Prettier 的,你可以全局配置,或者为单独项目配置

"prettier.eslintIntegration": true,
"prettier.singleQuote": true,
"prettier.semi": false,
"prettier.trailingComma": "all",
"prettier.endOfLine": "auto",
"prettier.useTabs": false,
"prettier.tabWidth": 2,

当然,Prettier 插件也支持 .prettierrc.js 文件,当项目中有该文件时,Prettier 插件就不会读取 VSCode 的设置了

module.exports = {
  singleQuote: false
};

你可能注意到了,Prettier 和 EditorConfig 有部分是重合的,例如 指定缩进大小 两者都可以配置

那么两者有什么区别呢?

我们可以看到 EditorConfig 的配置项都是一些通用的,不涉及具体语法的,什么 Tab 大小啦,缩进大小啦,文件编码啦,移除多余空格啦

而 Prettier 是一个格式化工具,要根据具体语法格式化,对于不同的语法用单引号还是双引号,加不加分号,哪里换行等,当然,肯定也有缩进大小

即使缩进大小这些设置,两者也是不冲突的

设置 EditorConfig 的 indent_size 和 tab_width 为 4,Prettier 的 tabWidth 为 2

image

image

注意,当写新的一行时光标的位置,还有编辑器显示地标尺的位置,这些是 EditorConfig 的效果

当保存时自动格式化,就变为下图的样子

image

a 标签的格式化

https://prettier.io/blog/2018/11/07/1.15.0.html#whitespace-sensitive-formatting

ESLint

...

ESLint vs Prettier

ESLint 不但可以在编辑时发现不好的语法和格式错误,还可以自动纠正,那么有什么事情 Prettier 可以做而 ESLint 不能做呢?好像没有欸,ESLint 的 auto-fix 就相当于 format 了啊

Prettier 的官方给出了与 Linters 的对比:https://prettier.io/docs/en/comparison.html

写的非常清晰,但是并没有给出 Prettier 强的地方

我在这里找到了答案:prettier/prettier-eslint#101

ESLint with Prettier

https://prettier.io/docs/en/eslint.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant