前端程式碼規範工程化實踐指南
現代前端技術飛速發展，前端已進入了以效率和質量為核心的工程化時代，各種自動化工具和技術的使用大大提高了開發效率。在團隊協作中，編碼規範至關重要，統一的編碼規範可以降低程式碼維護的成本，但是，純手工檢查程式碼規範費時費力且難以保證準確性，因此，針對程式碼規範的自動化工具應運而生，從最早的JSLint，到JSHint，再到今天的ESLint，程式碼規範工具變得越來越成熟。再結合WebStorm、VSCode等編輯器可以在編寫程式碼的時候自動提醒錯誤，在開發階段就避免錯誤，提高開發效率。本文主要討論前端工程化在程式碼規範上的一些實踐。
ESLint
ESLint是當前最流行的程式碼規範檢查工具，隨著ECMAScript版本一直更新，通過配置檢查規則來對程式碼進行規範檢查，具有豐富的外掛生態，也可以使用已有的規範以及進行自定義規則，可以滿足大部分團隊的需求。
下面介紹在react專案中如何使用ESLint。
首先，使用webpack搭建一個react的專案，在此不對具體搭建過程做具體介紹，然後使用npm安裝eslint：
在專案根目錄下新建.eslintrc檔案，用於配置eslint進行程式碼規範檢查的規則，下面是用於react專案的基本配置示例：
其中，parser用於指定eslint用來解析程式碼的解析器，babel-eslint是一個用於相容ESLint的babel解析器的封裝。env用於配置預定義的環境變數，此處指定了瀏覽器和Node.js以及ES6語法中所有的環境變數。parserOptions用於想要支援的JavaScript語言選項，此處指定了ecmaVersion和sourceType，分別表示啟用ES6語法以及ECMAScript模組。extends用於當前配置繼承何種規範，此處，使用airbnb公司開源的eslint-config-airbnb規範， eslint-config-airbnb規範預設包含了ES6+的語法以及React的語法，它依賴於eslint、eslint-plugin-import、eslint-plugin-react以及eslint-plugin-jsx-i11y等npm包，安裝時需要一起安裝。 使用npm5+的版本安裝eslint-config-airbnb：
rules即是配置的一系列規則，如果你不想使用airbnb中的某項規範，你可以在rules進行配置。下面列舉示例：
“semi”和“quotes”是ESLint中規則的名稱，第一個詞是錯誤級別，可以使用下面的值之一：
"off" or 0 ：關閉規則;
"warn" or 1 ：將規則視為一個警告（不會影響退出碼）;
"error" or 2 ：將規則視為一個錯誤 (退出碼為1);
也可以寫成如下的形式：
除了繼承，你還可以使用第三方外掛來配置規則，通過plugins來配置需要的外掛列表，以eslint-plugin-react為例，配置如下：
配置完成後，我們希望能在每次修改程式碼後再次編譯之前，能夠對程式碼進行自動檢查，先安裝eslint-loader：
增加Webpack配置：
Webpack使用babel-loader解析React的程式碼，增加eslint-loader的配置，enforce設定為pre可以讓Webpack在使用babel編譯之前執行eslint進行程式碼檢查。
eslint還提供了自動修復程式碼錯誤的能力，執行以下命令：
eslint會自動修復程式碼中的問題，但不是所有的問題都能被修復，剩餘未被修復的問題會列出。
ESLint還可以結合編輯器進行使用，首先保證使用了npm安裝了eslint以及生成了.eslintrc配置檔案，以WebStorm編輯器為例， 配置：
File -> Settings Languages & Frameworks -> JavaScript -> Code Quality Tools -> ESLint
勾選Enable即可。WebStorm就會在編寫程式碼的時候進行提示，如果不符合ESLint規則則會進行顏色標註，讓你更早發現程式碼問題。 
VSCode需要安裝eslint外掛才能對程式碼進行提示，在此不做贅述。
EditorConfig
不同的作業系統和編輯器對於文字的格式的支援會有一定的區別，如果不統一一些規範，可能在團隊協作的時候每次更新下來別人的程式碼就會一大堆報錯。 EditorConfig是一種多編輯器外掛，用於幫助開發者在不同的作業系統、編輯器和IDE之間定義和維護統一的程式碼風格。EditorConfig包含一個用於定義程式碼風格的配置檔案和對應的編輯器外掛，編輯器外掛可以讀取配置檔案並對程式碼進行格式化。 EditorConfig的配置檔案是.editorconfig，通常放置在專案根目錄下。EdtorConfig外掛對在資料夾的每一級目錄下查詢.editorconfig檔案，直到查詢到.editorconfig中包含root=true。 下面是一份.editorconfig配置檔案：（注意：不是每種外掛都支援下列所有屬性）
root為true表示是最頂層的配置檔案， [*]用於匹配需要格式化的程式碼，charset指定編碼格式為utf-8,intent_ style指定縮排風格為空格，還可以選擇tab，indent_ size用於指定縮排的列數，end_ of_ line指定換行符為lf，在Linux和Windows下可能會因為換行符lf和crlf的不一致導致程式碼被批量更改，insert_ final_ newline設為true表示檔案以一個空白行結尾， trim_ trailing_ whitespace設為true會去除換行行首的任意空白字元。
Webstorm編輯器預設已經內建了EditorConfig的外掛支援，只需要編寫配置檔案即可，VSCode需要下載EditorConfig的外掛使用。
與版本管理工具結合
以版本管理工具Git為例，當版本庫中出現commit、push等特殊事件時，都會觸發執行一個或者多個的Shell指令碼，稱之為git鉤子，存放在.git/hooks目錄下，鉤子從執行順序上分為兩類，前置（pre）和後置（post），分別發生在動作呼叫前後。 ESLint結合版本管理工具Git可以最大程度控制每個人的規範，在git commit程式碼的時候，使用git hook呼叫ESLint進行程式碼規範驗證，這樣可以保證團隊協作的程式碼是符合程式碼規範的，不規範的程式碼無法提交到倉庫。
配置Git鉤子的過程比較繁瑣，我們可以使用husky這個工具來簡化配置，husky使用如下：
安裝依賴：
修改package.json，增加script配置：
嘗試Git提交，會自動使用eslint進行校驗：
但是這樣會出現新的問題：如果一個老專案剛開始使用這種方式進行程式碼校驗，勢必會出現很多程式碼校驗不通過的情況。那麼最好的實現應該是開發者在commit程式碼的時候只校驗自己提交的部分，lint-staged解決了這個問題，statged指Git中的待提交區，使用git add然後git commit的時候，你的程式碼會經過待提交區。 lint-staged使用方法如下：
修改package.json中的script配置：
也可以使用如下配置自動修復錯誤：
husky會在.git/hooks中新增pre-commit鉤子，當開發者執行git add將程式碼提交到暫存區後，再執行git commit操作時，觸發pre-commit鉤子，開始執行npm run precommit命令，即lint-staged命令，lint-staged利用配置的檔案過濾路徑如（src/ */ .js），對暫存區檔案依次進行匹配，執行eslint --fix自動修復錯誤，並將修改新增到暫存區。
總結
程式碼是寫給人看的，順便讓機器執行。遵循統一的程式碼規範在團隊協作中可以極大提高開發效率，降低程式碼維護成本，而前端工程化可以讓這件事情變得更簡單。
今日推薦
