在 Create React App 項目中使用 Prettier

Prettier

前言

若是你只想知道如何在 WebStorm 或 VS Code 中,使用 Prettier 去自動格式化代碼,那就一拉到底,直奔主題吧。javascript

Prettier 介紹

Prettier 是一個「武斷的」(官網用詞:opinionated)代碼格式化工具。html

opinionated

它只提供了不多的配置項,剩下的一切,你都不用管了,主要是你想管也管不着,只能乖乖聽它的就好了。java

你看:prettier.io/docs/en/opt…,配置項真的不多,一拉到底,幾下就看完了。node

「武斷」的好處是,省去了研究繁瑣的配置,省去了無心義的爭論,一覺醒來,一個保存,代碼就 Prettier 了,你還沒辦法,一種無力感,很是絕望。react

  • 政治哲學:獨裁也是有好處的,若是獨裁者是個天才。
  • 產品哲學:給用戶增長選項很簡單,不去麻煩用戶很難。
  • Prettier 哲學:Shut up and listen to me.

Prettier 與 ESLint 的區別

咱們傾向於讓 ESLint 去判斷邏輯(代碼正誤),讓 Prettier 去判斷美(代碼樣式)。webpack

Dan Abramov 的解釋:github.com/facebook/cr…git

這種解耦也可讓總體邏輯更清晰,因此,二者都須要,一個也不能少。github

探索與嘗試(心路歷程)

1. 項目技術棧

Create React App 搭建項目,ESLint 使用 Airbnb JavaScript Styleweb

2. 結合 ESLint 與 Prettier

在已經使用 ESLint 的狀況下,第一反應固然是如何把 ESLint 與 Prettier 結合起來(前面說了,二者不一樣,不能拋棄任何一個)。npm

開發哲學中的一個基本理念:擁抱業界最佳實踐。不要自做聰明,不要浪費時間,總之,感謝開源世界,人生苦短,去抱大腿

因此就不要看各路網友曲藝雜談了,直奔 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,因此若是仍是什麼小問題的話,就只能本身探索了。

完了嗎?

完了。

相關文章
相關標籤/搜索