在 Create React App 项目中使用 Prettier

如果你只想知道如何在 WebStorm 或 VS Code 中，使用 Prettier 去自动格式化代码，那就一拉到底，直奔主题吧。

Prettier 介绍

Prettier 是一个「武断的」（官网用词： opinionated ）代码格式化工具。

它只提供了很少的配置项，剩下的一切，你都不用管了，主要是你想管也管不着，只能乖乖听它的就行了。

你看： prettier.io/docs/en/opt… ，配置项真的很少，一拉到底，几下就看完了。

「武断」的好处是，省去了研究繁琐的配置，省去了无意义的争论， 一觉醒来 ，一个保存，代码就 Prettier 了，你还没办法，一种无力感，非常绝望。

• 政治哲学：独裁也是有好处的，如果独裁者是个天才。
• 产品哲学：给用户增加选项很简单，不去麻烦用户很难。
• Prettier 哲学：Shut up and listen to me.

Prettier 与 ESLint 的区别

我们倾向于让 ESLint 去判断逻辑（代码正误），让 Prettier 去判断美（代码样式）。

Dan Abramov 的解释： github.com/facebook/cr…

这种解耦也可以让整体逻辑更清晰，所以，两者都需要，一个也不能少。

探索与尝试（心路历程）

1. 项目技术栈

Create React App 搭建项目，ESLint 使用 Airbnb JavaScript Style 。

2. 结合 ESLint 与 Prettier

在已经使用 ESLint 的情况下，第一反应当然是如何把 ESLint 与 Prettier 结合起来（前面说了，两者不同，不能抛弃任何一个）。

开发哲学中的一个基本理念：拥抱业界最佳实践。不要自作聪明，不要浪费时间，总之，感谢开源世界，人生苦短， 去抱大腿 。

所以就不要看各路网友曲艺杂谈了，直奔 Prettier 官网的解决方案： prettier.io/docs/en/esl…

如果对 ESLint 没那么熟悉，一个 eslint-plugin-prettier ，一个 eslint-config-prettier ，基本就懵了，这都干啥的呀？

了解之前需要说明一点：我一开始就形成了 ESLint 与 Prettier 两者相互独立的思维，事实上也确实是。所以看这配置就有点懵，直到顿悟 —— 在这里，Prettier 是作为 ESLint 的一个插件来用，所以它在这里是附属于 ESLint 的 —— 世界豁然开朗。

这俩兄弟干啥的就不具体介绍了，现在直接去看官网就行。

看到最后， Use both 方案，这个最简单，就它了。

2. Use both 的一个坑

不知道是版本问题，还是普遍存在，总之，在 Create React App v2 搭建的项目里，一旦你用了 Use both 方案，加在项目中的 .prettierrc 配置文件就是无效的，不起作用。

解决方案是，别 Use both 了，还是乖乖分开写吧，看这里： github.com/prettier/es…

分开写，似乎配置也更明了一些，挺好的。

3. 保存时自动 Prettier，还是 commit 时自动 Prettier？

第一反应，保存时去 Prettier 好。

4. 保存时自动 Prettier 的功能，配置在项目中，还是配置在 IDE 中？

第一反应，配置在项目中。

因为我们希望，项目一拉下来，一切都是可用的，尽量不要让用户去配置一些乌七八糟的东西，衣来伸手饭来张口，这是最好的。

产品哲学：给用户增加选项，就是给自己增加混乱。

5. 实现自动 Prettier 的两种方式

一种当然是使用 Prettier，直接 prettier --write xxx 就完事了。

另一种，其实 ESLint（cli）自带了一个 --fix 的功能，它也可以格式化代码。

前面已经说了，使用结合方案，Prettier 就是 ESLint 的一个插件，所以用 ESLint 的 fix 功能也没什么问题。

6. 如何将保存时自动 Prettier 的功能，配置在项目里

第一反应，最好不要增加任何 npm 包，与 cli 对应， eslint-loader 的 options 中也有一个 fix 。

呃，很遗憾，经尝试，配置 fix: true 后，这玩意儿并不起作用。看到这个 issue ，我把版本改为 2.1.0 ，还是没反应，崩溃，不可靠，不造为啥，放弃。

配置 eslint-loader 的方案走不通，只能加命令行 watch 代码变化，来调用自动格式化了。

7. package.json 中添加自动格式化命令行

Prettier 官网也有介绍，使用 onchange 库，观察变化，进行格式化，就完事了。

这里又得考虑一个问题，用户是懒惰的，运行 yarn start 已经够累了，难道还要他们再运行个 yarn prettier-watch 吗？

那他们肯定是不会运行的，加了等于白加，所以只能把 start 改成 yarn prettier-watch && react-scripts start 。

改成这样后，就会发现，后面的 react-scripts start 根本没走，崩溃。

还没来得及思考是不是用 concurrently 可以解决，就发现了别的问题。

我在 watch 中尝试了 prettier --write 和 eslint --fix 两种方案，但是，在 WebStorm 中，两者都有一个致命问题 —— 代码更新不是实时的。

保存代码，它是自动格式化了，但在编辑器中是看不到变化的，除非关了 tab 重新打开，或者切别的 tab 然后再切回来，才能看到变化，崩溃。

只能放弃这个方案了，这当然不是因为我用的就是 WebStorm，而是如果一个方案不普适，那就最好别用，我们得寻找最佳解决方案，Not one less.

IDE 实现有区别，这就好像是需要硬件支持，软件再优化也实在无能为力。

8. 拥抱 Create React App 官方方案

重新思考问题 3，「保存时自动 Prettier，还是 commit 时自动 Prettier？」

答案是：commit 时自动 Prettier。

这不是权宜之计，其实它才是 Create React App 官方钦定的方案，售后有保障，请看这里： facebook.github.io/create-reac…

我们要安慰自己，Create React App 官方可能也是考虑过各种 IDE 的差距，才给出这个方案的，人生苦短，还是不要苦海作舟了， 去抱大腿吧 。

9. 难道就要放弃「保存时自动 Prettier」这么迷人的功能了吗？

当然不是。

重新思考问题 4，「保存时自动 Prettier 的功能，配置在项目中，还是配置在 IDE 中？」

答案是：配置在 IDE 中。

「配置在项目中」实在是国军无能， 硬件 ，不对，IDE 支持不太行。

所以我们只能去追逐 IDE 支持良好的「配置在 IDE 中」了。

WebStorm 中实现 Prettier 自动格式化

看这里： prettier.io/docs/en/web…

版本过低的话，直接升级到 2018.1 and above ，这时候配置就很简单，网页上说的很清晰，别费时间研究旧版了，人生苦短 ...

因为希望不只格式化 .js 文件，还有 .jsx .scss 等，所以需要设置多个 File Watcher，分别处理不同文件类型。

默认是格式化整个项目的代码，难道把一些压缩代码也给格式化了？不合适！所以需要在 Scope 中将目录设置为 src 。

具体步骤：Scope -> 输入框后面的三个点 -> 左上角 + 号 -> Local -> 命名 -> 点开项目目录 -> 选中 src -> 右边点击 Include Recursively -> 保存。

VS Code 中实现 Prettier 自动格式化

看这里： prettier.io/docs/en/edi…

装个 prettier-vscode 插件就完事了，肥肠简单。

实现自动格式化的关键，VS Code 的配置中， editor.formatOnSave 改为 true 。项目中统一使用 .prettierrc 配置。我们不就是为了统一规范、云端插拔，所以就不需要在编辑器中设置 prettier.xxx 了。

因为我用的不是 VS Code，所以如果还是什么小问题的话，就只能自己探索了。