eslint+prettier+husky+lint-staged 統一前端代碼規範

eslint+prettier+husky+lint-staged 統一前端代碼規範

遵循編碼規範和使用語法檢測，能夠很好的提升代碼的可讀性，可維護性，並有效的減小一些編碼錯誤。

一、終極目標

團隊中的全部開發人員用一套代碼規範規則，而且無需咱們花太大的精力去爲了格式而格式。但願有一套自動化工具，幫咱們檢測代碼是否規範，若是不規範，則自動可以幫咱們按照既定規範格式化。

實現這一目標需解決的問題：

一、代碼規範落地難：面對開發規範常常面臨的現狀是很難落地，老是「拆東牆補西牆」，歸根結底在於須要工具去強行保證代碼必須通過代碼開發規範的掃描；

二、低質量代碼帶入線上應用：在開發現狀中開發人員能夠簡單的執行git push操做將本地代碼帶入遠程分支上，若是代碼質量低下就很容易對線上應用質量埋下隱患，最好的方式本地進行commit的時候，最起碼須要保證當前代碼可以知足團隊制定的開發規範，若是不經過，commit都沒法成功，這樣可以從最源頭保證代碼質量；

三、代碼格式難統一：現狀團隊開發成員代碼格式都有很大的不一樣，有些人字符串喜歡用雙引號，有的人喜歡使用單引號等等問題，若是代碼格式化問題不統一，互相查看其它人代碼很累，甚至代碼格式錯亂，嚴重影響代碼可讀性，無疑也增長了團隊內的溝通成本，針對這樣狀況，須要一種工具可以保證團隊內代碼的格式是一致；

四、代碼質量文化難落地：過引入代碼質量工具，在開發過程當中可以時刻對自身代碼質量進行約束，逐漸培養自身對代碼質量有「潔癖」的開發觀念，同時也會成爲團隊乃至自身對質量文化落地的一個抓手；

面對以上問題，eslint+prettier+husky+lint-staged 這幾個工具可以有效解決上述問題。

二、eslint 配置

ESLint 是一個Javascript Linter，幫助咱們規範代碼質量，提升團隊開發效率。

避免代碼錯誤、寫出最佳實踐、規範變量使用方式、規範代碼格式；

社區比較知名的代碼規範，eslint 配合這些代碼規範，可以檢測出代碼潛在問題，從而提升代碼質量。

官方提供了3種規範：

eslint-config-google：Google標準

eslint-config-airbnb：Airbnb標準,它依賴eslint, eslint-plugin-import, eslint-plugin-react, and eslint-plugin-jsx-a11y等插件，而且對各個插件的版本有所要求

eslint-config-standard：Standard標準，它是一些前端工程師自定的標準，

目前來看，公認的最好的標準是Airbnb標準。

2.1 默認配置

使用 Create React App 建立的 React 應用，默認安裝了ESLint依賴，package.json文件中的 eslintConfig 屬性只提供了用於發現常見錯誤的最小規則集。

 "eslintConfig": {
        "extends": "react-app"
   }

2.2 自定義配置

2.2.1 在根目錄下建立 .eslintrc.json 文件，完成一些基礎配置，代碼以下：

{
    // env：你的腳本將要運行在什麼環境中
    "env": {
        "browser": true,
        "es6": true,
        "jquery":true
   },
    // globals：腳本在執行期間訪問的額外的全局變量
    "globals": {
        "$": true,
        "process": true,
        "__dirname": true
   },
    // 指定ESLint使用的解析器，默認是Espree
    "parser": "babel-eslint",
     // 指定想要支持的 JavaScript 語言選項
    "parserOptions": {
        "ecmaFeatures": {
            "experimentalObjectRestSpread": true,
            "jsx": true,
            "modules": true
       },
        "sourceType": "module",
        "ecmaVersion": 7
   },
     //讓eslint支持 JSX start
    "plugins": ["react"],
    // 繼承已啓用的規則
    "extends": ["eslint:recommended"],
    // 啓用的規則及其各自的錯誤級別。自定義啓用或關閉一些規則
    "rules": {
        "react/jsx-uses-react": 1,
        "no-unused-vars": 0, //變量聲明未被使用校驗
        "no-empty": 0,
        "quotes": 0, //單引號
        "no-console": 0 //不由用console
   }
}

想具體瞭解各個配置什麼意思的，請參考官網：http://eslint.cn/docs/user-guide/configuring

2.2.2 配置完成，測試效果

完成上述配置以後，只會影響編輯器和 IDE 檢測與規則不符的代碼（好比在vscode中與規則不符的代碼有紅色的下劃波浪線），不會在控制檯和瀏覽器中出現相關提示。

2.3 擴展 ESLint 配置

因咱們項目使用react-app-rewired 對 Create React App 進行了自定義配置，因此須要修改config-overrides.js，修改後的代碼以下：

const { override, fixBabelImports, addWebpackAlias,useEslintRc } = require('customize-cra')
const path = require('path')
​
//重寫配置
module.exports = override(
  // 配置路徑別名
  addWebpackAlias({
    '@': path.resolve(__dirname, 'src')
 }),
  // antd按需加載
  fixBabelImports('import', {
    libraryName: 'antd',
    libraryDirectory: 'es',
    style: 'css'
 }),
  //啓用eslintrc配置文件
  useEslintRc()
)

通過上述配置後，eslint 生效，npm start 會在控制檯和瀏覽器中出現相關錯誤提示：

控制檯報錯：

瀏覽器報錯：

2.4 忽略特定的文件或目錄

在項目根目錄建立一個 .eslintignore 文件告訴 ESLint 去忽略特定的文件和目錄。.eslintignore 文件是一個純文本文件，其中的每一行都是一個 glob 模式代表哪些路徑應該忽略檢測。例如：

build/*.js
public
dist
node_modules
config
config-overrides.js
src/serviceWorker.js
prettierrc
.DS_Store
.eslintrc.json
node_modules

2.5 eslint fix自動修復

eslint --fix 能夠根據規範對代碼的部分低級問題進行更正，如：缺乏/多餘分號，縮進格式等。

可以修復的規範問題比較有限，須要較大變更才能修復的規範問題，eslint 沒法自動修復。如：單行不能超過 80 個字符。

自動修復src文件夾下.js文件和.jsx文件部分規範問題，命令以下：

eslint --fix --ext .js --ext .jsx src/

三、eslint集成prettier

prettier 是一個「武斷的」（官網用詞： opinionated ）代碼格式化工具。（只關心代碼格式，統一代碼風格）

根據規範，自動格式化代碼，具備比 eslint auto-fix 更增強大的代碼規範性修復能力。

官網：https://prettier.io/

3.1 安裝prettier

根據 prettier官方建議，Prettier 版本升級後可能會有風格變化，故應當鎖定 Prettier 的版本號。

npm install prettier --save-dev

3.2 安裝eslint-plugin-prettier

ESLint插件，eslint-plugin-prettier 做爲一個 ESLint的規則運行，並報告不一樣的單個ESLint問題。

將 prettier 的能力集成到 eslint 中。按照 prettier 的規則檢查代碼規範性，並進行修復。

npm install eslint-plugin-prettier --save-dev

修改.eslintrc.json文件：

第一種方式：

//插件增長prettier
"plugins": ["react","prettier"],
//繼承規則增長prettier
"extends": ["eslint:recommended","prettier"],
// 不符合 prettier 規則的代碼，要進行錯誤提示（紅線）
"rules":{
  "prettier/prettier":"error" 
},

第二種方式：

//至關於上面三個操做
{
    "extends": ["eslint:recommended","plugin:prettier/recommended"]
}

注：extends的含義

告訴 eslint，根據指定的規範，去檢查指定類型的文件。如上例：

根據 eslint:recommended + prettier 規範，去檢查 js 代碼。

當某一類型的文件，被制定了不止1個規範，存在某些規範衝突時，後面的會覆蓋掉前面的。

3.3 安裝eslint-config-prettier解決衝突（若是存在衝突）

npm install  eslint-config-prettier --save-dev

做用：解決衝突，讓全部可能會與 prettier 規則存在衝突的 eslint rule 失效，並使用 prettier 的規則進行代碼檢查。至關於用 prettier 的規則，覆蓋掉 eslint:recommended 的部分規則。

後面 prettier 格式化，也會根據這個規則來。所以，不會再有衝突。

3.4 prettier自動格式化

自動格式化src目錄下的文件，命令以下：

prettier --write 'src/**/*.{js,css,jsx,html}'

3.5 自定義配置

根目錄下新建.prettierrc文件，可根據須要進行一些自定義配置，示例以下：

{
   "printWidth": 100,
   "singleQuote": true,
   "trailingComma": "es5",
   "tabWidth": 4,
   "semi": true,
   "jsxBracketSameLine": false,
   "jsxSingleQuote": true,
   "useTabs": false
}

【注】這裏的 .prettierrc，具備格式化規則的最高優先級。

3.6 忽略特定的文件或目錄

在根目錄下新建.prettierignore文件，直接添加文件名和目錄名，與.eslintignore相似，示例以下：

build/*.js
public
dist
node_modules
config
config-overrides.js
src/serviceWorker.js
prettierrc
.DS_Store
.eslintrc.json
node_modules

prettier格式化的時候會忽略該配置文件中的文件或目錄

四、編輯器自動格式化代碼

4.1 使用編輯器快捷鍵，格式化代碼

以 vscode 爲例：shift + option + f，默認格式化規則選擇 prettier，便可完成代碼格式化。

4.2 保存代碼自動格式化

一樣以 vscode 爲例，打開你的 settings.json，添加下面這句話：

"editor.formatOnSave": true

至此jsx，js、json、scss等文件，都可實現自動格式化。文件格式化規則，聽從咱們在 .eslintrc.json 裏的配置。也就是，使用咱們的 prettier 插件規則去格式化。

五、規範檢查加強（husky + lint-staged）

在 git commit 以前，先強制執行prettier格式化（防止某些成員開發期間不開啓編輯器格式化）、再檢查代碼規範，若是檢查不經過、阻止提交。

5.1 安裝 husky

npm install husky --save-dev

husky: git hook工具。這裏主要用它防止不規範代碼被commit、push、merge等等。

5.2 安裝 lint-staged

npm install lint-staged --save-dev

Lint-staged提供了一個關鍵的功能，它能找到全部被git staged的文件，而不是工程下面全部的文件，而後經過管道交給Prettier作格式化。

5.3 配置husky和lint-staged

在package.json新增配置，以下：

    "husky": {
        "hooks": {
            "pre-commit": "lint-staged"
       }
   },
    "lint-staged": {
        "*.{js,jsx}": [
            "prettier --write",
            "eslint",
            "git add ."
       ]
   },

precommit由Husky處理，它會依照配置在把代碼提交到倉庫前運行lint-staged(也能夠配置其餘命令）。

Lint-staged再找到屬於它本身的配置部分，即lint-staged鍵下面的配置。

上面的配置，git commit 以前，全部staged狀態的，且擴展名是.js和.jsx的文件都會自動使用 prettier 格式化。格式化後，自動檢查全部文件，是否所有符合 eslint 規範。

存在不符合規範的代碼，git commit 將被終止。

修改代碼，進行測試，結果以下：

與預期徹底一致，若是有不符合代碼規範或語法錯誤的代碼提交不了。輸出錯誤信息，點擊可定位到錯誤位置。

爲什麼必定要用lint-staged？

爲何必定要用lint-staged，用Husky直接調用npm腳本不更簡單麼。配置以下：

 "scripts": {
        "start": "react-app-rewired start",
        "build": "react-app-rewired build",
        "test": "react-app-rewired test",
        "fix": "eslint --fix --ext .js --ext .jsx src/",
        "format": "prettier --write 'src/**/*.{js,css,jsx,html}'"
   },
  "husky": {
        "hooks": {
            "pre-commit": "npm run format && npm run fix"
       }
   },

若是是這樣配置的話，就沒有必要用lint-staged了。由於，這樣的配置會把prettier，eslint應用到全部匹配.js,.jsx的文件上，而不是僅staged狀態的文件。

5.4 husky擴展

5.4.一、單元測試檢測

把單元測試加入到預提交檢查中，保證只有經過了單元測試才正式提交代碼到倉庫。

配置以下：

 "husky": {
        "hooks": {
            "pre-commit": "lint-staged && npm test"
       }
   },

只是配上這個命令是不能跑的，仍是要集成Jest單元測試框架，編寫單元測試代碼。

5.4.二、commit messages規範與約束

git每次提交代碼，都必須寫commit message(提交說明)，用來講明本次提交的目的，不然不容許提交。

commit message的寫法規範有許多，目前使用最廣的，比較合理和系統化的一種規範：Angular 規範。

工具commitizen/cz-cli會產生規範性的提示語句，幫助咱們造成規範的commit message。

工具commitlint用於檢查咱們的commit message是否符合提交規範，若是不符合，則直接拒絕提交。

huskey配置以下：

 "husky": {
    "hooks": {
      "commit-msg": "commitlint -e $GIT_PARAMS"
   }
 }

5.5 husky不起做用怎麼辦

配置完成後 git commit 不起做用。

解決方案：確認 .git/hooks/* 下的文件，刪除對應命令的文件，從新執行安裝便可。

六、總結

規範僅僅經過人爲的培訓或者文檔來約束，是不可靠的。

能經過工具約束的儘可能經過工具約束，而不要依靠默契和口頭約定。

經過使用這些工具可以在必定程度上保證應用的質量問題，並能達到事半功倍的效果。

至此咱們開頭的終極目標已實現~~！

七、引用

https://www.jianshu.com/p/56bee5bf1568

https://www.jianshu.com/p/f0d31f92bfab

http://www.javashuo.com/article/p-cytevpsq-cy.html

http://www.javashuo.com/article/p-rnpmpayx-ha.html

http://www.javashuo.com/article/p-dcxyqyxr-ws.html

還有引用其它文章一些內容，再也不一一列舉了。。。。