在 Create React App 项目中使用 Prettier

5,757 阅读6分钟

Prettier

前言

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

Prettier 介绍

Prettier 是一个「武断的」(官网用词:opinionated)代码格式化工具。

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 方案,这个最简单,就它了。

3. Use both 的一个坑

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

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

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

4. 保存时自动 Prettier,还是 commit 时自动 Prettier?

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

5. 保存时自动 Prettier 的功能,配置在项目中,还是配置在 IDE 中?

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

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

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

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

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

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

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

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

第一反应,最好不要增加任何 npm 包,与 cli 对应,eslint-loaderoptions 中也有一个 fix

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

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

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

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

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

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

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

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

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

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

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

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

9. 拥抱 Create React App 官方方案

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

答案是:commit 时自动 Prettier。

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

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

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

当然不是。

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

答案是:配置在 IDE 中。

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

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

WebStorm 中实现 Prettier 自动格式化

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

版本过低的话,直接升级到 2018.1 and above,重点是 Running Prettier on save using File Watcher,可以先看看。

根据我的经验,最佳实践是:

先在项目中安装 Prettier:yarn add prettiernpm install prettier

然后 Preferences -> Tools -> File Watchers,点击左下角 + 号,选择 PrettierFile Type 选择 Any,然后 OK,再 OK,就添加好了 Watcher。

那怎么区分哪些目录或文件需要 Prettier 格式化,哪些不需要呢?

最好不要在 Scope 中自定义配置,建议使用 .prettierignore 文件设置忽略项,方式与 .gitignore 一样。

node_modules 是自动忽略的,有其它需求比如忽略 build 目录,添加 build 即可,忽略所有 png 文件,添加 *.png 即可。

这样的话,就可以一套配置统一项目所有开发人员,科学的、面向未来的配置方式,完美。

VS Code 中实现 Prettier 自动格式化

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

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

实现自动格式化的关键,VS Code 的配置中,editor.formatOnSave 改为 true

项目中统一使用 .prettierrc 配置,我们不就是为了统一规范、云端插拔,所以就不需要在编辑器中设置 prettier.xxx 了。

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

完了吗?

完了。