Prettier your project

简介

Prettier is an opinionated code formatter.

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

就最初的设计目标来说，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 的三倍之多，说明关注这个项目的人非常多。
• 再看项目的更新进度，基本每 1 - 2 天就会有新的提交，这个迭代速度说明更新以及问题解决的响应非常快。
• 还有 npm 上的下载量，达到了 400 万次 / 周，说明真正在使用的人也非常多。

从以上种种看出，这个项目的未来是充满光明的。

与 Eslint

比较

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

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

• Prettier 的定位是一个代码格式化工具（code formatter），其侧重点在于格式化（format），其目的是让你的代码变得更好看（prettier），可读（readable）。
• ESlint 的定位一个校验工具（linting utility），其侧重点在于校验，其目的是让代码更一致和避免 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 来说，它工作的领域仅限于第一类——格式化代码，也就是说即使存在严重影响代码质量（Code-quality）的问题——比如[死循环](https://eslint.org/docs/rules/for-direction)——Prettier 不会做出任何反应。原因将会在下文中做出（Rationale）说明。

格式化代码

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

集成

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

• 安装依赖

yarn add --dev eslint-config-prettier eslint-plugin-prettier

• 修改 ESlint 配置

// .eslintrc.json
{
  "extends": ["plugin:prettier/recommended"]
}

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

yarn add pretty-quick husky --dev

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "pretty-quick --staged"
    }
  }
}

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

1. 需要安装 prettier-vscode 插件。
2. 自定义格式化配置

{
  "editor.formatOnSave": true,
  "editor.formatOnType": true,
  "editor.formatOnPaste": true
}

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

设计原则

正确性（Correctness）

第一原则。作为一个代码格式化工具，如果想要让别人用的放心，在保证格式化代码后不会出现 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 = {}

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

// semi.js
if (shouldAddLines) {  
  [-1, 1].forEach(delta => addLine(delta * 20))
}

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

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

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

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

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

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

易读性

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

• 多行对象

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

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

// multi-line
const css = {  
    fontSize: 12,
    color: "red",
    padding: 100
};

但是如果仅仅通过长短来格式化，就无法针对不同类型的对象做格式化处理，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
};

• 测试方法

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

• 易加难减

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

• true - Example: { foo: bar } .
• false - Example: {foo: bar} .

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

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

尾声

最后，借用我偶像 Dan 对 Prettier 的一段 描述 来结尾：

I just wanted to take a moment to say there are some of us who actually appreciate tools with limited scope that don’t attempt to solve everybody’s use case, and instead do a specific thing well.

说明

• [1] 不格式化的某些情况下的 empty lines 以及 multi-line object
• [2] 之所以强调规范一词，是因为笔者曾经遇到过，有开发者因为代码校验无法通过，通过直接删除 node_modules，使 git 钩子无效化的方式强制推送代码。