在 Create React App 專案中使用 Prettier
如果你只想知道如何在 WebStorm 或 VS Code 中，使用 Prettier 去自動格式化程式碼，那就一拉到底，直奔主題吧。
Prettier 介紹
Prettier 是一個「武斷的」（官網用詞： opinionated ）程式碼格式化工具。
它只提供了很少的配置項，剩下的一切，你都不用管了，主要是你想管也管不著，只能乖乖聽它的就行了。
你看： ofollow,noindex">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 自動格式化
版本過低的話，直接升級到 2018.1 and above ，這時候配置就很簡單，網頁上說的很清晰，別費時間研究舊版了，人生苦短 ...
因為希望不只格式化 .js 檔案，還有 .jsx .scss 等，所以需要設定多個 File Watcher，分別處理不同檔案型別。
預設是格式化整個專案的程式碼，難道把一些壓縮程式碼也給格式化了？不合適！所以需要在 Scope 中將目錄設定為 src 。
具體步驟：Scope -> 輸入框後面的三個點 -> 左上角 + 號 -> Local -> 命名 -> 點開專案目錄 -> 選中 src -> 右邊點選 Include Recursively -> 儲存。
VS Code 中實現 Prettier 自動格式化
裝個 prettier-vscode 外掛就完事了，肥腸簡單。
實現自動格式化的關鍵，VS Code 的配置中， editor.formatOnSave 改為 true 。專案中統一使用 .prettierrc 配置。我們不就是為了統一規範、雲端插拔，所以就不需要在編輯器中設定 prettier.xxx 了。
因為我用的不是 VS Code，所以如果還是什麼小問題的話，就只能自己探索了。