摘要：梳理前端開發使用檢查和格式化代碼問題痛點在團隊的項目開發過程中，代碼維護所占的時間比重往往大于新功能的開發。使用格式化所有代碼。參考文檔如何花分鐘解決產生的各種錯誤的記憶現場原文轉載梳理前端開發使用檢查和格式化代碼線上猛如虎，線下慫如鼠

在團隊的項目開發過程中，代碼維護所占的時間比重往往大于新功能的開發。因此編寫符合團隊編碼規范的代碼是至關重要的，這樣做不僅可以很大程度地避免基本語法錯誤，也保證了代碼的可讀性。

對于代碼版本管理系統（svn 和 git或者其他），代碼格式不一致帶來的問題是嚴重的，在代碼一致的情況下，因為格式不同，觸發了版本管理系統標記為 diff，導致無法檢查代碼和校驗。

但是需要知道的是，開發規范不僅僅包含代碼格式規范，還有很多內容，這里只是多帶帶說明代碼格式化規范而已。

使用 eslint 檢查代碼

使用 prettier 格式化代碼（prettier是 eslint —fix 的加強版）

使用 editorconfig 協助兼容開發工具的代碼格式化

鑒于網上文章說明的比較混亂，這里主要是為了梳理整個流程和思路，然后對比網上的文章重新理解和學習 eslint 和 prettier 和代碼檢查和代碼格式化。

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

webstorm（或者JetBrains: Developer Tools for Professionals and Teams系列開發軟件）

vscode （Visual Studio Code - Code Editing. Redefined）

安裝不同ide 編輯器的對應的 eslint 插件和 prettier 插件

安裝 eslint 和 prettier （node 模塊）

配置 eslint 和 prettier

配置團隊使用的 rules

配置 editorconfig

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

開發工具可以做很多東西，是開發代碼的利器，但是不同的開發工具會有不同的代碼提示，代碼格式化，代碼檢查的機制，這樣的差異化會對團隊代碼規范（開發和檢查）帶來很多問題，所以需要統一。

當然，如果個人不愿意更換自己用慣的開發工具的話，也沒關系，只要能夠做到跟團隊的開發規范保持一致也是可以的，但個人覺得，這樣難度比較大，畢竟開發工具和團隊的開發規范不那么容易融合。

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

~webstorm 或者 vscode 分別安裝好之后需要安裝eslint 插件和 prettier 插件。~

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

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

WebStorm 2018.1 和以上的版本

WebStorm 2017.3 和更早的版本

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

官方默認已經集成了 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

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

這個版本有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 插件，然后點擊安裝。（prettier 插件沒截圖，但類似）
[image:478E5E36-1056-4C77-8D98-D009559070CB-2833-000008A49B4C4EFC/D8C1E6E5-619D-48BA-93C8-EBA1091B9FBD.png]

安裝完畢之后點擊 ~重新加載~ 以激活插件。

vscode 的快捷鍵：

CMD + Shift + P -> Format Document

或者

Select the text you want to Prettify

CMD + Shift + P -> Format Selection

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

安裝這個模塊的意義在于，實際上，整個流程最核心就是這個地方，開發工具雖然支持了這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文件的代碼。

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 的檢查規則是通過配置文件.prettierrc 實現的，不過一般來說，只需要配置少部分規則即可：

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

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

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

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

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

整個代碼檢查和格式化流程應該規范為如下步驟：

使用eslint 并且嘗試自動修復所有問題（eslint 有 autofix 提示，可以進行—fix 修復，按照 .eslintrc 配置文件來進行修復）。

使用 prettier 格式化所有代碼。

差異性修復代碼，因為有些格式或者其他問題導致出錯而被前兩部過濾之后還剩余的。（通常前面兩步基本解決了所有問題了）

把精美的格式化后的代碼提交到版本庫。

參考文檔：

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

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