eslint+husky+prettier+lint-staged提高前端應用質量

時間 2019-11-05

標籤 eslint+husky+prettier+lint eslint husky prettier lint staged 提高前端應用質量简体版

原文原文鏈接

1. 引入掃描工具的初衷

1.1 針對痛點

目前在梳理前端應用時發現不少代碼不規範的地方，包括簡單的js問題以及代碼格式化的問題，形成了代碼可讀性降低，另外各類歷史代碼也是「風格迥異」，一個應用是被來自」五湖四海「人共同維護，難難免有」廣式燒臘、天津狗不理「各類口味，更不免的還有」臭味相投「的，這些狀況嚴重影響了應用質量。應用開發成員大部分因爲以前是開發後端，對前端開發經驗不足以及許多前端知識體系都是在開發過程當中現學現用慢慢積累的，另外，痛定思痛總在想對於前端應用代碼質量是否也存在諸如Java開發規約掃描插件，相似的前端代碼質量掃描插件進行把控。通過查閱資料，採用eslint+husky+prettier+lint-staged方式來對前端質量進行必定程度上的提高，之因此採用這樣的方式，針對的痛點以下：html

代碼規範落地難：代碼規約至關於團隊乃至公司的整個技術團隊協做的契約，同時這些規範是通過許許多多前輩大師通過項目的洗禮留下的寶貴財富能夠在開發中少走不少的彎路，可是，面對開發規範常常面臨的現狀是很難落地，老是「拆東牆補西牆」，歸根結底在於須要工具去強行保證代碼必須通過代碼開發規範的掃描；
低質量代碼帶入線上應用：在實際開發現狀中開發人員能夠很簡單的執行git push操做將本地代碼帶入遠程分支上，若是代碼質量低下就很容易對線上應用質量埋下隱患，至於在合併的時候在進行CR，這樣反饋鏈路太長，最好的方式本地進行commit的時候，最起碼須要保證當前代碼可以知足團隊制定的開發規範，若是不經過，commit都沒法成功，這樣可以從最源頭保證代碼質量問題；
代碼格式難統一：按照現狀團隊的開發成員對代碼的格式都有很大的不一樣，甚至有些人字符串喜歡用雙引號，有的人喜歡使用單引號等等問題，若是代碼格式化問題不統一，總以爲互相查看其它人的代碼總以爲怪怪的，甚至代碼格式錯亂，嚴重影響了代碼可讀性，無疑也增長了團隊內的溝通成本，針對這樣的狀況，須要一種工具可以保證團隊內代碼的格式是一致；
代碼質量文化難落地：經過引入代碼質量工具，在開發過程當中可以時刻對自身代碼質量進行約束，逐漸培養自身對代碼質量有「潔癖」的開發觀念，同時也會成爲團隊乃至自身對質量文化落地的一個抓手。

針對以上痛點，採用eslint+husky+prettier+lint-staged這幾個工具可以有效解決上述問題，其中執行流程和原理在下面給出（同時關於對代碼質量文化另外一個抓手—CR也可見於《入Ali一年，對code-review的思考》）。前端

1.2 達成效果

要想防患於未然，防止將存在潛在問題的代碼帶到線上環境，最好的辦法是在本地提交代碼時就可以掃描出潛在的錯誤，並強制將其修改後才能提交，這樣就不會將問題代碼攜帶到線上，就能保證線上代碼至少不會存在低級的程序錯誤。針對這樣的訴求，能夠採用husky、lint-staged、eslint以及prettier插件來實現，具體效果以下：java

如上圖，當試圖commit代碼時，因爲掃描出錯誤就不能進行提交成功，必須將其修改爲功方可commit。react

1.3 配置文件

在前端應用中的package.json中新增以下文件：git

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": [
      "eslint --fix --ext .js",
      "prettier --write",
      "git add"
    ]
  },
  "devDependencies": {
    "eslint": "^5.0.0",
    "eslint-config-ali": "^2.0.1",
    "eslint-plugin-import": "^2.6.0",
    "eslint-plugin-react": "^7.1.0",
    "husky": "^0.14.2",
    "babel-eslint": "^8.1.1",
    "lint-staged": "^4.0.0",
    "prettier":"^1.16.4",
    "eslint-plugin-prettier":"^3.0.1",
    "eslint-config-prettier":"^4.0.0"
  },
}
複製代碼

增長.eslintrc.js掃描規則：github

module.exports = {
  "extends": ["eslint-config-ali","prettier", "plugin:prettier/recommended"],
  "parser": "babel-eslint",
  "rules": {
    "prettier/prettier": "error",
    "strict": "off",
    "no-console": "off",
    "import/no-dynamic-require": "off",
    "global-require": "off",
    "require-yield": "off",
  },
  "plugins": ["prettier"],
  "globals": {
    "React": "readable"
  }
};

複製代碼

增長.prettierrc.js文件，用於在掃描經過後格式化代碼（該步驟可選，若是不引入prettier的話，相應的在package和eslintrc中去除掉相應配置便可）web

module.exports = {
  printWidth: 80,
  semi: true,
  singleQuote: true,
  trailingComma: 'none',
  bracketSpacing: true,
  jsxBracketSameLine: false,
  arrowParens: 'avoid',
  requirePragma: false,
  proseWrap: 'preserve'
};
複製代碼

在前端工程中引入以上的配置文件便可，這樣就能夠達到1.3中的效果。置於其中的實現原理在下面進行分析，有興趣的能夠繼續往下看npm

2. 實現原理

2.1 執行流程

達到上述效果，執行的流程以下：json

待提交的代碼git add 添加到暫存區；
執行 git commit；
husky註冊在git pre-commit的鉤子函數被調用，執行lint-staged；
lint-staged 取得全部被提交的文件依次執行寫好的任務（ESLint 和 Prettier）；
若是有錯誤（沒經過ESlint檢查）則中止任務，同時打印錯誤信息，等待修復後再執行commit；
成功commit，可push到遠程

在上述流程中，有這樣幾個核心點：segmentfault

husky註冊git的鉤子函數保證在git 執行commit時調用代碼掃描的動做；
eslint完成按照配置的規則進行掃描；
Lint-staged保證只對當前add到git stage區的文件進行掃描操做，這樣作的緣由在於，若是對全工程的文件進行掃描的話，而且以前的前端工程並未注重代碼規則的檢測的話，很大可能性會出現成百上千的error，基本上內心是崩潰的。所以，只對當前add的文件進行檢測，達到及時止損的目的，歷史代碼能夠切到新的分支進行修復後再進行合併。

2.2 插件說明

在2.1中的執行流程中主要使用到eslint，lint-staged等插件，下面分別對這幾個插件進行說明。

2.2.1 eslint

lint是什麼?

lint是對前端代碼按照代碼規則進行靜態掃描的工具，主要負責對當前本地代碼進行規範檢查，若是不符合當前制定的規範則lint則會報出error，而且和lint-staged結合使用就會保證未經過代碼規範的檢查不能被提交到遠程分支上，這樣就能保證線上代碼的質量。

爲何要引入eslint？

引入eslint在個人思考中能夠具有以下的優勢：

既然是代碼掃描的工具，天然能夠保證開發規約的落地，諸如java開發規約的掃描插件，對於前端而言eslint就是這樣的一個工具，經過配置代碼規範來確保指定的代碼規約進行落地。常見的一些大廠的代碼規範有阿里的前端規範，airbnb，鵝廠alloyteam團隊等；
確保應用的線上質量，這點無須贅述，結合其餘工具的使用，不知足代碼規範的代碼都不能push到遠程分支上去；
更高的可讀性，eslint會對代碼質量進行掃描，而且通常結合prettier使用的話，在經過代碼規範後能夠對代碼進行格式化，能夠保證代碼可讀性；
避免低級的錯誤，經過eslint --fix能夠根據規範對代碼的部分低級問題進行更正。

怎樣使用eslint？

按照文章開頭給出的package.json進行配置便可，關於lint的使用能夠看官方文檔，eslint配置的代碼規範也在文章給出的eslintrc.js中給出，所謂代碼規範天然而然是根據團隊現狀指定的，咱們當前採用的是阿里前端規範eslint-config-ali，固然也能夠按根據現狀」因地制宜「的去制定。另外須要指出的是，在eslintrc.js配置文件中配置了globals變量：

"globals": {
  "React": "readable"
}
複製代碼

這是由於前端使用的React框架，eslint會對React等變量進行掃描會報出no-undefined的error，須要另其爲global變量才能避開掃描。在eslint的rules的設計中是可配置化的，在rules的屬性中能夠設置，具體eslint的rule可見官方文檔，其中打勾的是eslint:recommended推薦使用的規則。

2.2.2 husky

試想若是將代碼已經push到遠程後，再進行掃描發現多了一個分號而後被打回修改後才能發佈，這樣是否是很崩潰，最好的方式天然是確保本地的代碼已經經過檢查才能push到遠程，這樣才能從必定程度上確保應用的線上質量，同時也可以避免lint的反饋流程過長的問題。

那麼何時開始進行掃描檢查呢？這個時機天然而然是本地進行git commit的時候，若是能在本地執行git commit操做時可以觸發對代碼檢查就是最好的一種方式。這裏就須要使用的git hook。

什麼是git的hook

git的hook能夠理解成當執行如git add、git commit等git操做時的回調，能夠查看.git文件下的hooks目錄，這裏存放的是git相關操做的一些腳本例子。經過git hook就能夠在本地進行commit的時候觸發代碼掃描來確保本地代碼的質量。關於git hook能夠看這篇文章。

2.2.3 lint-staged

在使用eslint和husky可以保證代碼的質量問題，可是在實際工程中卻還必須面臨一個問題。現實狀況下，一個應用通常是多個開發參與，而且在應用的生命週期中還涉及到人員變動，這就意味着一個應用是被來自」五湖四海「人共同維護，難難免有」廣式燒臘、天津狗不理「各類口味，更不免的還有」臭味相投「的。

針對這些歷史代碼時，若是提交代碼時，對其餘未修改文件都進行檢查，一下出現成百上千個錯誤，估計會嚇得立馬刪掉管理eslint的配置，冒出一身冷汗。以下圖所示（來源於網絡）

修改了A文件，B、C、D等文件的錯所有都冒出來了。針對這樣的痛點問題，就是每次只對當前修改後的文件進行掃描，即進行git add加入到stage區的文件進行掃描便可，完成對增量代碼進行檢查。如何實現呢？這裏就須要使用到lint-staged工具來識別被加入到stage區文件。關於lint-stage能夠看官方文檔，如今會過頭來看package.json文件就可以理解其中的意思：

"scripts": {
  "precommit": "lint-staged"
},
"lint-staged": {
  "src/**/*.js": [
    "eslint --fix --ext .js",
    "prettier --write",
    "git add"
  ]
},
複製代碼

在進行git commit的時候回觸發到git hook進而執行precommit，而precommit腳本引用了lint-staged配置代表只對git add到stage區的文件進行掃描，具體lint-staged作了三件事情：1. 執行eslint --fix操做，進行掃描，若發現工具可修復的問題進行fix；2. 執行prettier腳本，這是對代碼進行格式化的，在下面具體來講；3. 上述兩項任務完成後對代碼從新add。

2.2.4 prettier

Prettier工具主要用來統一代碼格式的，eslint也會對代碼進行必定程度的格式校驗，但主要是用來對代碼規範的掃描，而prettier則是專門用來對代碼進行格式化，兩個工具各司其職，爲代碼質量進行保駕護航。它的主要原理是將格式化前的代碼和格式化後的代碼進行比對，若是發現不同，prettier就會對其進行標記並按照指定的格式化規範進行修復。下面的圖能夠看出prettier的能力（配套來源於網絡）

能夠看出prettier可以對代碼進行格式化，這樣就能夠保證代碼的可讀性。perttier可以支持多種格式如JSX、HTML等等，具體可查看官方文檔，對代碼格式化標準能夠根據團隊現狀共同來決定。

與eslint配合使用的插件

爲了和eslint配合使用須要引入兩個插件eslint-plugin-prettier和eslint-config-prettier，其中須要說明的是eslint-config-prettier插件的做用，這個插件是若是eslint的規則和prettier的規則發生衝突的時候（主要是沒必要要的衝突），例如eslint 限制了必須單引號，prettier也限制了必須單引號，那麼若是用 eslint 驅動 prettier 來作代碼檢查的話，就會提示2種報錯，雖然他們都指向同一種代碼錯誤，這個時候就會由這個插件來關閉掉額外的報錯。關於eslint-config-prettier能夠看它的官方文檔。