vue-run

# Prettier

Prettier

# 简介

Prettier is an opinionated code formatter.

从官网的介绍中我们可以看到，首先 Prettier 的定位是一个代码格式化工具，并且比较任性（opinionated）。它移除了几乎所有原始格式，来确保所有输出的代码符合一致。

几乎所有原始格式

不格式化的某些情况下的 empty lines 以及 multi-line object

就最初的设计目标来说，Prettier 面向的范围主要还是 Web 端的一些开发语言，如：

  • JSX
  • CSS, Less , and SCSS
  • GraphQL
  • ... 不过作为一款代码格式化工具，Prettier 通过开放了插件（Beta）的能力，来对不同语言提供支持。

# 为什么要用

对于代码风格的圣战，没有一天真正停止过：

  • Tab V.S. space
  • single V.S. double quote
  • Semicolons
  • ...

就个人角度来说，这些争论有意义吗？我觉得是有的，因为不仅体现了一个程序员对细节的追求，还锻炼了探索、深挖、求真的能力。但是就团队的角度来说，我觉得这些争论是没有意义的，个人代码的风格大相径庭，从 ESlint 的规则数量就可以明显地看出这一点。如果从个人代码风格的角度出发，制定一套适用于团队层面的规范，讨论到最后，很难有一个统一的结果。 所以，为了统一团队代码风格，确实需要任性（opinionated），才能真正落地。

# 对新人友好

当有新人进入一个团队时，他不仅需要熟悉业务流程，兼顾遗留代码，如果在开发时还被一系列的格式化代码规则磕磕绊绊，是非常不友好的一件事。而通过配置 Prettier，按下一个按键就可以直接将代码格式化，不需要为了适配各种规则手动修改，能将更多精力放在代码质量层面。

# 易于适应

除了一些非常有争议的风格作为配置项，Prettier 内置的规则经过了多次修改讨论，对于大多数开发者来说，是比较容易接受的。

# 关于未来

我们引入一个新工具，肯定希望它是稳步上升的，如果用到一半就被废弃，后续的解耦成本就会成为一个新的问题。 所以一个工具的未来如何一个非常重要的考量点：

  • 作为一个 Facebook 出品的工具，其雄厚的技术实力肯定是我们不容小觑的。
  • 在 GitHub 上的 star 数，是老大哥 ESlint 的3 倍之多，说明关注这个项目的人非常多。
  • 再看项目的更新进度，基本每1 ~ 2 天就会有新的提交，这个迭代速度说明更新以及问题解决的响应非常快。
  • 还有 npm 上的下载量，达到了 400 万次 / 周，说明真正在使用的人也非常多。

从以上种种看出，这个项目的未来是潜力巨大的。

# 与 Eslint 比较

每当提到 Prettier，ESlint 一定是一个绕不过去坎。甚至有人觉得两者是冲突的，是包含与被包含的关系。但是在我看来，他们只是存在某些功能上的重合，硬要从这个角度来说，顶多也是存在交集的关系。

要搞清楚两者的关系，可以先从定义上解读它们之间的区别：

  • Prettier 的定位是一个代码格式化工具，其侧重点在于格式化，其目的是让你的代码变得更好看，可读。
  • ESlint 的定位一个校验工具，其侧重点在于校验，其目的是让代码更一致和避免 bug。

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.

简单来看，它们相同的地方主要有以下几点：

  1. 都期望能够减少甚至避免产生 bug。
  2. 都期望统一代码风格。
  3. 都具备格式化代码的功能。

# 统一代码风格

ESlint 规则成千上万，主要可以分为两大类：

  1. 格式化代码规则（Formatting rules）：如 max-len , no-mixed-spaces-and-tabs , keyword-spacing , comma-style ...

  2. 代码质量规则（Code-quality rules）：如 no-unused-vars , no-extra-bind , no-implicit-globals , prefer-promise-reject-errors ...

理想情况下，如果 ESlint 规则设置的足够细致，基本能保证两个不同的开发者——采用相同的技术方案——在代码风格上 90% 的一致性。 但是对于 Prettier 来说，它工作的领域仅限于第一类——格式化代码，也就是说即使存在严重影响代码质量的问题——比如死循环——Prettier 不会做出任何反应。原因将会在下文中做出说明。

# 格式化代码

ESlint 本身是一个代码校验工具，但是也提供了格式化代码的功能，通过添加 --fix 参数，可以将代码格式成符合自定义规则的样子。 Prettier 作为专业的格式化工具，内部自建了一套关于代码风格的规则，且这些规则无法被修改，除了暴露出的 19 个的配置项。这么做的目的，就是为了停止对各种个性化风格优劣的争论，从而将讨论的重点转移到这19 个配置项中。

# 集成

在我们的日常开发过程中，已经习惯了使用 ESlint 来保障代码质量与统一风格。如果再加上 Prettier 作为代码格式化的工具，就可以起到如虎添翼的效果。但是因为 Prettier 内建的规则可能和 ESlint 的规则产生冲突，所以需要通过配置插件来解决这些问题。 - Eslint 检验自定义规则的同时，还能支持 Prettier 的规则； - 我们希望 Prettier 格式化后的代码是符合 Eslint 规则的，但是因为 Prettier 内建规则是无法修改的，所以当两种的规则冲突时，需要以 Prettier 的规则为主。 通过下面的步骤可以达到上述条件所描述的：

  • 创建配置文件，有三种方式：
  1. 根目录创建.prettierrc 文件，能够写入 YML、JSON 的配置格式，并且支持.yaml/.yml/.json/.js后缀；
  2. 根目录创建.prettier.config.js文件，并对外 export 一个对象；
  3. 在 package.json中添加 prettier 选项参数。

在 vscode 中有对应的支持插件，以下是我使用的相关首选项配置:

Prettier

  • 安装依赖
npm i eslint-config-prettier eslint-plugin-prettier -D
1
  • 修改 ESlint 配置
// .eslintrc.json
{
  "extends": ["plugin:prettier/recommended"]
}
1
2
3
4

如果在项目中使用 Prettier，我们当然不希望每次都要手动去执行格式化的命令，通过定制 pre-commit钩子，可以达到自动格式化的效果，详见文档。 我个人最常用的是pretty-quick，开箱即用。配置好后，每次将文件提交到 git 暂存区（stage）之前，都会自动对所有文件做格式化。这样一来，只要开发者按照规范 的流程走，就避免了代码格式不一致问题。

npm i pretty-quick husky -D
1
// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "pretty-quick --staged"
    }
  }
}
1
2
3
4
5
6
7
8

除了通过使用 git hooks 的方式来格式化代码，也可以在编码过程中，直接对其进行格式化。以 VSCode 为例：

{
   "editor.formatOnSave": true,
  "editor.formatOnType": true,
  "editor.formatOnPaste": true
  // ...
  "prettier.eslintIntegration": true,
  "prettier.semi": false, // 每一行末尾加上分号
  "prettier.singleQuote": true, // 用单引号
  "prettier.printWidth": 200, // 换行字符串阈值
  "prettier.tabWidth": 2,
  "prettier.trailingComma": "none", // (x) => {} 是否要有小括号
  "prettier.stylelintIntegration": true
  // ...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

这一步也可以通过Formatting Toggle 插件来实现。

# 设计原则

# 正确性

第一原则。作为一个代码格式化工具，如果想要让别人用的放心，在保证格式化代码后不会出现 bug 的同时，也必不能对原代码做任何入侵。这就是上文中提到的，即使出现了 bug，Prettier 也不会做出反应，仅关注如何更好地代码的原因。eslint --fix 则不同，它会去格式化那些违反规则的代码：

return '' + value

// after eslint --fix
return `${value}`

{
  color: color
}
// after eslint --fix
{
  color
}

let a = {}
// after eslint --fix
const a = {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

保证正确性的另一个方面，就是能够提前预知格式化后可能会产生的 bug。看下面一个例子：

// test.js
if (shouldAddLines) {
  ;[-1, 1].forEach(delta => addLine(delta * 20))
}
1
2
3
4

通过prettier semi.js --no-semi命令对上述代码格式化，最后得到的结果是这样的：

if (shouldAddLines) {
  ;[-1, 1].forEach(delta => addLine(delta * 20))
}
1
2
3

看上去似乎不符合规则，其实这么做事为了避免下述情况：

if (shouldAddLines) {
  ;+console.log('Do we even get here??')[(-1, 1)].forEach(delta => addLine(delta * 20))
}

// after format
if (shouldAddLines) {
  console.log('Do we even get here??')[(-1, 1)].forEach(delta => addLine(delta * 20))
}
1
2
3
4
5
6
7
8

通过上面的例子，说明了 Prettier 并非通过一刀切的方式对代码进行格式化，还会考虑格式化后的代码，在具体的应用场景中会如何。

# 易读性

在我们日常开发的过程中，经常会遇到一些涉及性能的问题。解法很多，但是我一般会选择更加容易让人看懂的那种。也就是说在一般情况下，为了代码的可维护性是可以牺牲一部分性能的。 **格式化代码不是目的，目的是为了让代码更加易读。**可以通过以下几个列子看出 Prettier 是如何遵守这一规则的：

  • 多行对象

    对象的书写方式一般由以下两种：短对象可以写在一行里，而一些长对象或者类 CSS 对象我们习惯多行书写。

    // single-line
const user = { name: 'John Doe', age: 18 }

// multi-line
const css = {
  fontSize: 12,
  color: 'red',
  padding: 100
}
    1
    2
    3
    4
    5
    6
    7
    8
    9

    但是如果仅仅通过长短来格式化，就无法针对不同类型的对象做格式化处理，Prettier 也考虑到了这一点，可以通过下面的方式来自己选想要的格式化结果。

    // before
const use = { name: 'John Doe', age: 18 }

// after
const user = { name: 'John Doe', age: 18 }
/**--------------------------------------**/

// before
const use = {
  name: 'John Doe',
  age: 18
}

// after
const user = {
  name: 'John Doe',
  age: 18
}
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18

  • 测试方法

    在一些测试方法中，可能必有比较长的描述说明，导致长度超过了既定值。但是 Prettier 并不会去做强制换行处理，因为这样做是没有意义的，只会降低可读性。

  • 易加难减

到目前位置，Prettier 的配置规则仅仅只有 19 条，虽然添加一个规则不是什么难事，但是如果要将规则删除，就存在很大的问题了。你可以试想下如果将来某一天 Prettier 的一条规则被删除了，会发生什么？以 bracket-spacing 为例： 在删除之前，无论我的配置是 trueor false，格式化话后的对象都是遵循一定规则的：

// true
const example = { foo: bar }

// false
const example = {foo: bar}
1
2
3
4
5

但是如果规则被删除，不复存在了，你的代码中可能会存在{foo: bar, } 这样的结果，这是大家都不愿意看到的。就拿 PR 来说，我在代码比对的过程中看到的这个属于格式上的不统一，在我引入了 Prettier 之后，这个问题理应是不会存在的，渐渐大家就会失去对这个工具的信任。

为什么要举 bracket-spacing 这个例子呢，因为这是一个连 Prettier 的作者也不知道为什么会存在的配置规则，但是它现在依旧存在着。

# 资料

最近更新时间: 1/10/2020, 5:47:17 PM

← ESlint →