在 Create React App 專案中使用 Prettier

南小北發表於2018-11-20

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,這時候配置就很簡單,網頁上說的很清晰,別費時間研究舊版了,人生苦短 ...

因為希望不只格式化 .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,所以如果還是什麼小問題的話,就只能自己探索了。

完了嗎?

完了。

相關文章