用 husky 和 lint-staged 構建超溜的代碼檢查工做流

具有基本工程素養的同窗都會注重編碼規範，而代碼風格檢查（Code Linting，簡稱 Lint）是保障代碼規範一致性的重要手段，你的工做流中有 Lint 環節麼？有的話你用的爽麼？你在團隊中推廣過 Lint，可是你們都不買帳？到底是爲啥？

Lint 是什麼？

探討怎麼作以前，咱們頗有必要給 Lint 來個清晰、準確的定義，wikipedia 的定義以下：

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.

簡單來講，Lint 就是對代碼作靜態分析，並試圖找出潛在問題的工具，實戰中咱們也用 Lint 來指使用工具的過程。

爲何要 Lint？

使用 Lint 會有什麼好處呢？在我看來至少具備以下 3 點：

• 更少的 Bug，劍橋大學的研究發現，全世界每一年由於軟 Bug 形成的經濟損失約 3120 億美金；
• 更高的開發效率，工程師平均會花掉 50% 的工做時間定位和解決各類 Bug，其中不乏那些顯而易見的低級錯誤，而 Lint 很容易發現低級的、顯而易見的錯誤；
• 更高的可讀性，代碼可讀性的首要因子是「表面文章」，表面上看起來亂糟糟的代碼一般更難讀懂；

能夠絕不客氣的說，若是你不作 Lint，就是在浪費本身的時間，浪費公司的資源。既然作 Lint 的預期效果很好？該怎麼作呢？

提交後 Lint：反饋鏈條太長？

說到怎麼作，多數人會天然而然的想到各類 Lint 工具，目前社區中針對各類語言都開發了 Lint 工具，前端能用到的就有大把：ESLint、Standard、SCSSLint、JSONLint、HTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是個很是不錯的參考。

不少同窗選擇在持續集成階段（後文用 CI 代稱）作 Lint，好比使用遠程的 Git Hooks 來觸發。可是從實際的經從來看，這種作法的反饋鏈條一般以下：

代碼提交 --> 發現問題(遠程) --> 修復問題 --> 從新提交 --> 經過檢查(遠程)複製代碼

整個過程可能會浪費掉你很多時間，畢竟 CI 過程一般不只是在作 Lint，若是你是那種不知道本身時間天天都去哪兒了的工程師，能夠反思下本身或者團隊的工做流是不是這樣。而且，請相信我，你不是少數人。

你有沒有這樣的經歷：吭哧吭哧寫了幾天代碼，各類驗收都經過了，最後被 CI 拒絕，竟是由於你的代碼中少加了一個逗號，這時候心情簡直崩潰到沒法形容：

從 GitHub 上各類修復 Lint 的提交數量不難發現工程師在修復 Lint 問題上浪費的時間，好比搜索 "fix lint"，多達 45W 次提交：

再好比搜索 「fix indent」，多達 226W 次提交，是否是很觸目驚心？

只在 CI 流程作 Lint 的缺點也是顯而易見的：

• Lint 在整個開發工做流中的反饋鏈條太長，浪費時間、注意力和資源，最致命的；
• CI 流程搭建成本比較高，即便 Travis CI 這種服務，步驟也仍是比較繁瑣；

咱們該怎麼改進？

提交前 Lint：錯誤信息不相關？

爲了縮短 Lint 的反饋鏈條，把 Lint 挪到本地是最有效的辦法。常見作法是使用 husky 或者 pre-commit 在本地提交以前作 Lint。

使用 husky 的具體作法以下：

首先，安裝依賴：

npm install -D husky複製代碼yarn add --dev husky複製代碼

而後修改 package.json，增長配置：

 
 
 
  { 
 
  
 

 
  
  
  

 

  
  "scripts": { 

 
  
  
  

 

  
  "precommit": "eslint src/**/*.js" 

 
  
  
  

 

  
  } 

 
  
  
  

 

  
  } 

 
複製代碼

最後嘗試 Git 提交，你就會很快收到反饋：

git commit -m "Keep calm and commit"複製代碼

可是在遺留代碼倉庫上工做的同窗很快會遇到新的問題，開啓 Lint 初期，你可能會面臨成千上萬的 Lint Error 須要修復。部分同窗對下面這個圖可能並不陌生：只改了文件 A，可是文件 B、C、D 中也有大量錯誤。

把整個倉庫都格式化不失爲一種選擇，可是實際上須要很大的勇氣。多數人在項目中運用新工具都但願是漸進式的，而不是推到重來式的，由於相比而言，業務系統穩定是更重要的事情。簡單的把 Lint 挪到本地，反饋鏈條是縮短了，可是面對每次改動，工具仍是給出了太多不相關的信息，這無疑與小步快跑的互聯網節奏是相違背的。

該怎麼破？

只 Lint 改動的：66666

若是把 Lint 挪到本地，而且每次提交只檢查本次提交所修改的文件，上面的痛點就都解決了。Feedly 的工程師 Andrey Okonetchnikov 開發的 lint-staged 就是基於這個想法，其中 staged 是 Git 裏面的概念，指待提交區，使用 git commit -a，或者先 git add 而後 git commit 的時候，你的修改代碼都會通過待提交區。

lint-staged 用法以下：

首先，安裝依賴：

npm install -D lint-staged複製代碼yarn add --dev lint-staged複製代碼

而後，修改 package.json 配置：

 

  
  { 

 
  
  
  

 

  
  "scripts": { 

 
  
  
  

 

  
  "precommit": "lint-staged" 

 
  
  
  

 

  
  }, 

 
  
  
  

 

  
  "lint-staged": { 

 
  
  
  

 

  
  "src/**/*.js": "eslint" 

 
  
  
  

 

  
  } 

 
  
  
  

 

  
  } 

 
複製代碼

最後，嘗試提交的效果：

實際上，lint-staged 給了你提交前代碼操做的更大自由度，好比使用下面的配置，自動修復錯誤：

 

  
  { 

 
  
  
  

 

  
  "scripts": { 

 
  
  
  

 

  
  "precommit": "lint-staged" 

 
  
  
  

 

  
  }, 

 
  
  
  

 

  
  "lint-staged": { 

 
  
  
  

 

  
  "src/**/*.js": ["eslint --fix", "git add"] 

 
  
  
  

 

  
  } 

 
  
  
  

 

  
  } 

 
複製代碼

或者使用下面的配置，自動格式化代碼（謹慎使用）：

 

  
  { 

 
  
  
  

 

  
  "scripts": { 

 
  
  
  

 

  
  "precommit": "lint-staged" 

 
  
  
  

 

  
  }, 

 
  
  
  

 

  
  "lint-staged": { 

 
  
  
  

 

  
  "src/**/*.js": ["prettier --write", "git add"] 

 
  
  
  

 

  
  } 

 
  
  
  

 

  
  } 

 
複製代碼

此外，lint-staged 和 prettier 已經集成到 create-react-app 中了。你是否是也應該好好打磨下本身的 Lint 工做流了？

總結

有人說前端攻城獅是世界上最奇怪的動物，提交代碼時用 prettier 把代碼排版的很美觀，但部署上線時又使用 uglify 把代碼壓縮的連親媽都不認了，事實是，若是咱們寫出來的代碼原本就很醜陋，就根本不須要用 uglify。但願讀到這裏的你能把 Lint 工做流打磨到極致，把更多時間專一在解決真正的問題上，成爲真正高效的工程師。

One More Thing

本文做者王仕軍，商業轉載請聯繫做者得到受權，非商業轉載請註明出處。若是你以爲本文對你有幫助，請點贊！若是對文中的內容有任何疑問，歡迎留言討論。想知道我接下來會寫些什麼？歡迎訂閱個人掘金專欄或知乎專欄：《前端週刊：讓你在前端領域跟上時代的腳步》。