梳理前端開發使用eslint-prettier檢查和格式化代碼

梳理前端開發使用eslint-prettier檢查和格式化代碼

問題痛點

• 在團隊的項目開發過程當中，代碼維護所佔的時間比重每每大於新功能的開發。所以編寫符合團隊編碼規範的代碼是相當重要的，這樣作不只能夠很大程度地避免基本語法錯誤，也保證了代碼的可讀性。
• 對於代碼版本管理系統（svn 和 git或者其餘），代碼格式不一致帶來的問題是嚴重的，在代碼一致的狀況下，由於格式不一樣，觸發了版本管理系統標記爲 diff，致使沒法檢查代碼和校驗。

可是須要知道的是，開發規範不只僅包含代碼格式規範，還有不少內容，這裏只是單獨說明代碼格式化規範而已。

解決辦法原理

1. 使用 eslint 檢查代碼
2. 使用 prettier 格式化代碼（prettier是 eslint —fix 的增強版）
3. 使用 editorconfig 協助兼容開發工具的代碼格式化

文章大綱：

鑑於網上文章說明的比較混亂，這裏主要是爲了梳理整個流程和思路，而後對比網上的文章從新理解和學習 eslint 和 prettier 和代碼檢查和代碼格式化。

1. 統一團隊使用的開發工具（ide 編輯器）

   1. webstorm（或者JetBrains: Developer Tools for Professionals and Teams系列開發軟件）
   2. vscode （Visual Studio Code - Code Editing. Redefined）
   3. 安裝不一樣ide 編輯器的對應的 eslint 插件和 prettier 插件
2. 安裝 eslint 和 prettier （node 模塊）

3. 配置 eslint 和 prettier

   1. 配置團隊使用的 rules
4. 配置 editorconfig
5. 嚴格督查，按照流程檢查和格式化代碼，按照規範和要求進行代碼提交。

第1、統一團隊使用的開發工具（ide 編輯器）

開發工具能夠作不少東西，是開發代碼的利器，可是不一樣的開發工具會有不一樣的代碼提示，代碼格式化，代碼檢查的機制，這樣的差別化會對團隊代碼規範（開發和檢查）帶來不少問題，因此須要統一。

固然，若是我的不肯意更換本身用慣的開發工具的話，也不要緊，只要可以作到跟團隊的開發規範保持一致也是能夠的，但我的以爲，這樣難度比較大，畢竟開發工具和團隊的開發規範不那麼容易融合。

這裏只說明前端業界目前最經常使用的兩種開發工具來作例子，分別是 webstorm 和 vscode。

~webstorm 或者 vscode 分別安裝好以後須要安裝eslint 插件和 prettier 插件。~

安裝webstorm 的eslint 插件和 prettier 插件並啓用插件

更多配置方式參考： WebStorm Setup · Prettier

根據官方介紹webstorm 分別有2種處理：

1. WebStorm 2018.1 和以上的版本
2. WebStorm 2017.3 和更早的版本

若是用IntelliJ IDEA, PhpStorm, PyCharm, and other JetBrains IDEs, 則須要安裝prettier插件和 eslint 插件，而webstorm 的話默認會幫你安裝上。

WebStorm 2018.1 和以上的版本

官方默認已經集成了 prettier 支持，只須要配置好一個全局的 prettier 模塊調用方式就可使用了（必須配置）。

[image:92501044-1ADD-41CB-BD0C-A08BF017856E-2833-0000064BE8D16DB1/5CC2BD82-B4E3-459A-A96A-8652870832E8.png]

快捷鍵是：Alt-Shift-Cmd-P on macOS or Alt-Shift-Ctrl-P on Windows and Linux

氪金王的好處，升級快，支持快，免破解，省心省力不省錢！

WebStorm 2017.3 和更早的版本

這個版本有2種狀況：

• ①是eslint 模式，使用 eslint-plugin-prettier 插件和啓用eslint 插件配合，這裏至關於使用 eslint 模塊來驅動 prettier 模塊，而後中間驅動則是靠eslint-plugin-prettier。

首先啓用 eslint，而且配置 eslint 模塊位置，默認會自動讀取當前目錄的 eslint.rc 配置文件，而後須要進行 npm 安裝eslint-plugin-prettier這個插件，後面再統一說明。
[image:45E71C29-2933-4178-8B54-1624D7BDE6ED-2833-0000080224C7A18F/F82912F6-0F7C-4D89-9A2C-EA1C8CF41469.png]

• ②是直接使用 prettier 做爲額外工具來使用。

[image:EB38EB6E-FB83-4C2B-B3FE-005FB45D1B81-2833-00000778833EC282/223C3C42-AE59-4501-9119-E44ACB0C38EE.png]

[image:BE8CDA11-63C4-4661-93BB-146299063BD9-2833-0000077989F51D06/2DE327F9-2274-448E-816A-D53057B4FB6F.png]

---

上面兩種方式的默認快捷鍵都是Cmd/Ctrl-Shift-A（在 mac 下是 comm+shift+A），以爲不舒服，按需修改快捷鍵便可。

[image:BD12F495-B168-485D-9E1B-CA30E07D4917-2833-000007DCC3947E10/36E1EB4E-769A-456D-B7F4-C1C61FD76086.png]

安裝 vscode的eslint 插件和 prettier 插件

打開 VSCode 擴展面板並搜索 ESLint 插件 和 prettier 插件，而後點擊安裝。（prettier 插件沒截圖，但相似）
[image:478E5E36-1056-4C77-8D98-D009559070CB-2833-000008A49B4C4EFC/D8C1E6E5-619D-48BA-93C8-EBA1091B9FBD.png]

安裝完畢以後點擊 ~從新加載~ 以激活插件。

vscode 的快捷鍵：

1. CMD + Shift + P -> Format Document

或者

1. Select the text you want to Prettify
2. CMD + Shift + P -> Format Selection

官網有詳細介紹：GitHub - prettier/prettier-vscode: Visual Studio Code extension for Prettier

第2、安裝 eslint 和 prettier （node 模塊）

安裝這個模塊的意義在於，實際上，整個流程最核心就是這個地方，開發工具雖然支持了這2個模塊，可是最終運行是必需要以這2個模塊安裝好才能使用的。

這是 node 的模塊，用 nam 或者 yarn 的方式安裝，如下是以 npm 安裝爲例。

nam -g install eslint eslint-plugin-prettier eslint-config-prettier babel-eslint prettier eslint-plugin-html --save-dev

• 使用-g是由於這些都是全局使用的模塊（尤爲是 eslint 和 prettier），不用每次重複安裝，並且也容易被開發工具找到，固然也能夠選擇不用-g，自行處理模塊位置。
• eslint 和prettier 不說。

• eslint-plugin-prettier 是以前說過，這裏從新說明一下：

  • 這個是在低版本的 webstorm 裏面使用 prettier 時候要求安裝的插件。
  • eslint 要跟 prettier 配合，須要有這個插件來作過渡（或者叫驅動），低版本的 webstorm 用到這個插件也是這個意思。

• eslint-config-prettier ：

  • 這個插件是若是eslint的規則和prettier的規則發生衝突的時候（主要是沒必要要的衝突），例如eslint 限制了必須單引號，prettier也限制了必須單引號，那麼若是用 eslint 驅動 prettier 來作代碼檢查的話，就會提示2種報錯，雖然他們都指向同一種代碼錯誤，這個時候就會由這個插件來關閉掉額外的報錯。
  • 但若是是eslint 只負責檢測代碼，prettier 只負責格式化代碼，那麼他們之間互不干擾，也就是說，也是能夠不安裝這個插件的，可是由於團隊的人員的差別性（即便同一個開發工具也有版本差別，也有使用 prettier 和 eslint 的差別），可能有存在各類狀況，因此最好仍是安裝上這個插件。
  • 官方有詳細介紹：GitHub - prettier/eslint-config-prettier: Turns off all rules that are unnecessary or might conflict with Prettier.

• babel-eslint ：

  • 有些代碼是沒被 eslint 支持的（由於 babel 也是負責這種事情，轉譯不被支持的 js 語法），因此須要加上這個插件來保持兼容性。
  • 官方有詳細介紹：https://github.com/babel/babe...

• eslint-plugin-html：

  • 問了讓eslint 能夠檢查.vue文件的代碼。

第3、配置 eslint 插件和 prettier插件

eslint 的配置

eslint 的檢查規則是經過配置文件.eslintrc 實現的，可是各家有各家的 eslint 配置文件GitHub - AlloyTeam/eslint-config-alloy: AlloyTeam ESLint 規則：

[image:183FFECA-1463-4847-995C-7968ACB07CDE-2833-00000FC1A80835A6/A9CB9340-A21E-42C9-ADF2-76B4351FA7D2.png]

詳細參考網址：

• AlloyTeam ESLint 規則
• 擺脫使人抓狂的ESlint 語法檢測配置說明 - web攻城方略 - SegmentFault 思否
• ESLint配置文件.eslintrc參數說明 · GitHub

不過這裏不糾結用哪種 eslint 的配置，具體看項目和團隊，這裏只是說明須要作 eslint 的配置，而且須要作一些說明：

.eslintrc 配置文件須要添加修改地方，主要是爲了 prettier插件和eslint-config-prettier 插件和eslint-plugin-prettier插件使用的：

// 原extends: 'eslint:recommended',
  extends: ['prettier', 'eslint:recommended'],
  // required to lint *.vue files 使用 html參數
  plugins: ['html', 'prettier'],

在 webstorm 下：

• 在項目根目錄.eslintrc做爲配置文件。

在 vscode 下：

• 在項目根目錄.eslintrc做爲配置文件。
• 而後依次點擊 文件 > 首選項 > 設置 打開 vscode 配置文件，而後配置指定使用哪一個 eslintrc 文件做爲 vscode 的配置文件。

[image:21128230-D925-4913-9B21-68C26C371CB6-2833-000010E826578238/162A9A99-B87A-469B-82FD-A570A7352937.png]

[image:BB2B7C90-692F-4731-93DC-D48E5E5F63FD-2833-000010E936A05A4C/6566C009-8837-4BA7-BC56-4F8EEF8AA928.png]

"eslint.options": {
    "configFile": "E:/git/github/styleguide/eslint/.eslintrc.js"
},

• 在 VSCode 中，默認 ESLint 並不能識別 .vue、.ts 或 .tsx 文件，須要在「文件 => 首選項 => 設置」裏作以下配置：

{
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        "html",
        "vue",
        "typescript",
        "typescriptreact"
    ]
}

詳細參考：使用 VSCode + ESLint 實踐前端編碼規範 - decoder - SegmentFault 思否

prettier的配置

prettier 的檢查規則是經過配置文件.prettierrc 實現的，不過通常來講，只須要配置少部分規則便可：

{
  "printWidth": 100,
  "singleQuote": true, // 這個地方須要跟 eslint 的規則保持一致
  "semi": false // 這個地方須要跟 eslint 的規則保持一致
}

官方有詳細的介紹：Configuration File · Prettier

這個配置在 webstorm 下和 vscode 都同樣。

第4、配置 editorconfig

• EditorConfig能夠幫助開發者在不一樣的編輯器和IDE之間定義和維護一致的代碼風格。
• EditorConfig包含一個用於定義代碼格式的文件和一批編輯器插件，這些插件可讓編輯器讀取配置文件並依此格式化代碼。

對此我我的的理解就是，editorconfig能夠協助開發工具在自動格式化或者自動排版或者錄入排版的時候進行代碼格式化，可是隻能支持比較簡單的規則，不過也減輕了一部分代碼格式化的壓力和成本，因此有比沒有好，並且最好要有。

// 放在項目根目錄的.editorconfig文件
root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

詳細參考：

• 【譯】EditorConfig介紹 | AlloyTeam
• EditorConfig

第5、嚴格督查，按照流程檢查和格式化代碼，按照規範和要求進行代碼提交。

須要明確一點，代碼格式化須要由上而下執行，若是沒有強制性壓力督促，那麼是對抗不了人類的惰性的。

整個代碼檢查和格式化流程應該規範爲以下步驟：

1. 使用eslint 而且嘗試自動修復全部問題（eslint 有 autofix 提示，能夠進行—fix 修復，按照 .eslintrc 配置文件來進行修復）。
2. 使用 prettier 格式化全部代碼。
3. 差別性修復代碼，由於有些格式或者其餘問題致使出錯而被前兩部過濾以後還剩餘的。（一般前面兩步基本解決了全部問題了）
4. 把精美的格式化後的代碼提交到版本庫。

參考文檔：

• 如何花30分鐘解決 eslint 產生的各類錯誤 | Tomyail的記憶現場

---

原文轉載：梳理前端開發使用 eslint+prettier 檢查和格式化代碼 | 線上猛如虎，線下慫如鼠（WhyNotBetter）