多人協作中統一的代碼風格有利于項目的發展這是共識，但是采用什么標準來統一代碼這選擇就相對紛雜。項目剛開始使用了ESLint來規范代碼，但是ESLint默認是支持JavaScript，加上配置可以支持TypeScript，而樣式的支持則需要再配置StyleLint，所以后面在項目中引入了Prettier這個統一的方案。

因為最開始使用的ESLint的standard來規范JavaScript和TypeScript代碼所以切換到Prettier的時候不方便做大的改動，所以Prettier的采用目的是規范JavaScript和TypeScript腳本之外的文件，例如：CSS | LESS | HTML | JSON | Markdown等文件。

但是在使用Prettier的時候出現了如下問題：

No parser and no filepath given, using 'babel' the parser now but this will throw an error in the future. Please specify a parser or a filepath so one can be inferred.

這個問題的描述其實很清楚了，就是說需要指定一個parser或者提供一個文件名來幫助Prettier推斷使用哪個parser。這個問題是我在使用Prettier的api的時候發現的，我的使用方式是prettier.check(source, config)這里的srouce是一個string類型這是源碼，源碼直接提供給Prettier，那么這個source到底是什么類型的文件Prettier并不清楚，是JavaScript呢還是CSS呢還是其他的什么呢？這時候需要在第二個參數config中給Prettier提供一個filepath字段給Prettier推斷源碼類型的線索，這樣就解決了這個問題。

Prettier有什么好處？

在Prettier的官網有介紹Prettier的好處以及與lint的區別，總結如下：

Prettier是一個固執的武斷的樣式格式化工具，怎么理解這句話呢？

Prettier是一個有主見的代碼格式化工具，不會像ESLint一樣給你很多配置項，讓你去選擇。Prettier的格式是固定的，只有少部分可以配置，并且這些配置也是因為一些不可抗力保留下來，可以預見的是這些配置不會急劇擴展，因為每增加一個配置就離Prettier減少樣式爭論的初衷越遠。

Prettier不會修改AST

Prettier做的事情只是print，也就是將AST根據自己的規則打印出來，并且Prettier是從頭到尾打印整個AST，而不是遇到一個節點判斷是否合理，不合理就改掉，合理就保留，它是打印整個AST，從頭到尾。

Prettier不會告訴你哪里錯了

Prettier不會告訴你哪個語法不符合規范，然后在編輯器中標紅，然后告訴你怎么改，而是直接幫你格式化。在使用prettier --check檢查文件時也不會直接告訴哪里有問題，而是告訴你哪些文件沒有沒有運行Prettier，其實這就意味著你只要運行了Prettier那么就不會存在這個問題。但是用過ESLint的同學都知道ESLint的--fix可不是這樣的，很多問題修復不了，需要自己手動修復。

Prettier只關注代碼風格

相對于ESLint既關注代碼風格也可以關注代碼質量（例如：標識符聲明了沒使用，var 轉const等）來說Prettier只關注代碼風格，不關注代碼質量，所以需要代碼質量控制還是需要配合lint類工具。

Prettier因為只做代碼風格檢查所以可以沒有上下文，也就意味著可以檢查代碼片段，也就是說 a = 1 這樣的代碼Prettier是可以通過。但是在ESLint中這個代碼片段是不合法的，因為在使用a的時候必須要先聲明標識符a。通過Prettier的這個特性就可以真正的實現代碼風格的增量檢查，而不是文件的增量檢查。

Prettier支持很多語言風格指導

Prettier不只包含了JavaScript和TypeScript的代碼風格還有很多其它語言的風格，上面就提到了CSS | LESS | HTML | JSON | Markdown還有很多其它語言的擴展。

總結

以上是生活随笔為你收集整理的代码风格之Prettier简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。