若是你只想知道如何在 WebStorm 或 VS Code 中,使用 Prettier 去自動格式化代碼,那就一拉到底,直奔主題吧。javascript
Prettier 是一個「武斷的」(官網用詞:opinionated)代碼格式化工具。html
它只提供了不多的配置項,剩下的一切,你都不用管了,主要是你想管也管不着,只能乖乖聽它的就好了。java
你看:prettier.io/docs/en/opt…,配置項真的不多,一拉到底,幾下就看完了。node
「武斷」的好處是,省去了研究繁瑣的配置,省去了無心義的爭論,一覺醒來,一個保存,代碼就 Prettier 了,你還沒辦法,一種無力感,很是絕望。react
- 政治哲學:獨裁也是有好處的,若是獨裁者是個天才。
- 產品哲學:給用戶增長選項很簡單,不去麻煩用戶很難。
- Prettier 哲學:Shut up and listen to me.
咱們傾向於讓 ESLint 去判斷邏輯(代碼正誤),讓 Prettier 去判斷美(代碼樣式)。webpack
Dan Abramov 的解釋:github.com/facebook/cr…git
這種解耦也可讓總體邏輯更清晰,因此,二者都須要,一個也不能少。github
Create React App 搭建項目,ESLint 使用 Airbnb JavaScript Style。web
在已經使用 ESLint 的狀況下,第一反應固然是如何把 ESLint 與 Prettier 結合起來(前面說了,二者不一樣,不能拋棄任何一個)。npm
開發哲學中的一個基本理念:擁抱業界最佳實踐。不要自做聰明,不要浪費時間,總之,感謝開源世界,人生苦短,去抱大腿。
因此就不要看各路網友曲藝雜談了,直奔 Prettier 官網的解決方案:prettier.io/docs/en/esl…
若是對 ESLint 沒那麼熟悉,一個 eslint-plugin-prettier
,一個 eslint-config-prettier
,基本就懵了,這都幹啥的呀?
瞭解以前須要說明一點:我一開始就造成了 ESLint 與 Prettier 二者相互獨立的思惟,事實上也確實是。因此看這配置就有點懵,直到頓悟 —— 在這裏,Prettier 是做爲 ESLint 的一個插件來用,因此它在這裏是附屬於 ESLint 的 —— 世界豁然開朗。
這倆兄弟幹啥的就不具體介紹了,如今直接去看官網就行。
看到最後,Use both
方案,這個最簡單,就它了。
Use both
的一個坑不知道是版本問題,仍是廣泛存在,總之,在 Create React App v2 搭建的項目裏,一旦你用了 Use both
方案,加在項目中的 .prettierrc
配置文件就是無效的,不起做用。
解決方案是,別 Use both
了,仍是乖乖分開寫吧,看這裏:github.com/prettier/es…
分開寫,彷佛配置也更明瞭一些,挺好的。
第一反應,保存時去 Prettier 好。
第一反應,配置在項目中。
由於咱們但願,項目一拉下來,一切都是可用的,儘可能不要讓用戶去配置一些烏七八糟的東西,衣來伸手飯來張口,這是最好的。
產品哲學:給用戶增長選項,就是給本身增長混亂。
一種固然是使用 Prettier,直接 prettier --write xxx
就完事了。
另外一種,其實 ESLint(cli)自帶了一個 --fix
的功能,它也能夠格式化代碼。
前面已經說了,使用結合方案,Prettier 就是 ESLint 的一個插件,因此用 ESLint 的 fix
功能也沒什麼問題。
第一反應,最好不要增長任何 npm 包,與 cli 對應,eslint-loader
的 options
中也有一個 fix
。
呃,很遺憾,經嘗試,配置 fix: true
後,這玩意兒並不起做用。看到這個 issue,我把版本改成 2.1.0
,仍是沒反應,崩潰,不可靠,不造爲啥,放棄。
配置 eslint-loader
的方案走不通,只能加命令行 watch 代碼變化,來調用自動格式化了。
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 實現有區別,這就好像是須要硬件支持,軟件再優化也實在無能爲力。
從新思考問題 3,「保存時自動 Prettier,仍是 commit 時自動 Prettier?」
答案是:commit 時自動 Prettier。
這不是權宜之計,其實它纔是 Create React App 官方欽定的方案,售後有保障,請看這裏:facebook.github.io/create-reac…
咱們要安慰本身,Create React App 官方可能也是考慮過各類 IDE 的差距,纔給出這個方案的,人生苦短,仍是不要苦海做舟了,去抱大腿吧。
固然不是。
從新思考問題 4,「保存時自動 Prettier 的功能,配置在項目中,仍是配置在 IDE 中?」
答案是:配置在 IDE 中。
「配置在項目中」實在是國軍無能,硬件,不對,IDE 支持不太行。
因此咱們只能去追逐 IDE 支持良好的「配置在 IDE 中」了。
版本太低的話,直接升級到 2018.1 and above,重點是 Running Prettier on save using File Watcher,能夠先看看。
根據個人經驗,最佳實踐是:
先在項目中安裝 Prettier:yarn add prettier
或 npm install prettier
。
而後 Preferences -> Tools -> File Watchers,點擊左下角 + 號,選擇 Prettier,File Type 選擇 Any,而後 OK,再 OK,就添加好了 Watcher。
那怎麼區分哪些目錄或文件須要 Prettier 格式化,哪些不須要呢?
最好不要在 Scope 中自定義配置,建議使用 .prettierignore
文件設置忽略項,方式與 .gitignore
同樣。
node_modules
是自動忽略的,有其它需求好比忽略 build
目錄,添加 build
便可,忽略全部 png
文件,添加 *.png
便可。
這樣的話,就能夠一套配置統一項目全部開發人員,科學的、面向將來的配置方式,完美。
裝個 prettier-vscode
插件就完事了,肥腸簡單。
實現自動格式化的關鍵,VS Code 的配置中,editor.formatOnSave
改成 true
。
項目中統一使用 .prettierrc
配置,咱們不就是爲了統一規範、雲端插拔,因此就不須要在編輯器中設置 prettier.xxx
了。
由於我用的不是 VS Code,因此若是仍是什麼小問題的話,就只能本身探索了。
完了。