使用 ESlint、lint-staged 半自動提高項目代碼質量

最近在項目部署了ESlint還有一些配套的工具，好比 prettier husky lint-staged，有些心得寫出來分享下。

依據本篇能夠實如今git commit之時，從新格式化代碼，同時進行代碼檢查預防一些低級錯誤。最終期待項目中的開發人員提交到線上的代碼符合代碼規範、風格統一，看起來像是一我的寫的。

實現過程

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

嗯……這個任務鏈看起來挺長的，但不要怕，也只是須要裝的模塊有點多罷了。
能夠當作兩個部分，代碼整理部分、pre-commit 函數部分。

husky 註冊 git hook

安裝

npm i --save-dev husky lint-staged

添加 hook 函數

// package.json { ... "scripts": { ... "precommit": "lint-staged", // git commit 執行這個命令，這個命令在調起 lint-staged }, "lint-staged": { // lint-staged 配置 "app/**/*.{js,jsx}": [ "prettier --tab-width 4 --write", "eslint --fix", "git add" ] }, ... } 

這裏 lint-staged 的配置是：在 git 的待提交的文件中，在 app 目錄下的全部 .js .jsx 都要執行三條命令。前兩條一下子說，後一條是將處理過的代碼從新 add 到 git 中。

粘貼的時候記得刪掉註釋，咱們知道JSON是沒有註釋的

prettier 格式化代碼

prettier 是強大的代碼格式化工具，目的是統一團隊的代碼格式。相對於 ESlint 代碼檢查能力較弱。

安裝

npm i --save-dev --save-exact prettier

而後……就完成了~ 🎉🎉🎉

這裏解釋下剛纔寫在 lint-staged 裏的命令參數

prettier --tab-width 4 --write

--tab-width 4 ：使用4個空格做爲縮進 （嗯，我更喜歡2個，不過……咱們的代碼規範是4個 😷）
若是想用tab做爲縮進能夠加上--use-tabs， 這時--tab-width表明tab數量。

--write：默認prettier是直接標準輸出到終端的，這個配置表明直接改寫文件。

關於prettier的還有一些配置參考這裏

ESLint

ESLint 相對來講是比較複雜的部分，不少次我都被繁多的規則和海量的報錯嚇退過，但好在概念很容易理解，在翻看別的開源項目的時候，發現真正要自行配置的規則也不過爾爾。

而ESLint的做用主要是爲了檢查代碼有沒有錯誤，有沒有不和代碼規範的地方。雖然 ESLint 有 --fix 的選項，能夠自動修復一些格式上的問題，但程度並不能和 Prettier 至關。

Prettier的概念更像是不管你怎麼寫，走到我這裏，都會被格式成我這一種樣子。而ESLint 只在發現問題的地方進行 fix，這是二者在邏輯上有區別。

配置 ESLint 主要是配置規則，規則從何而來，那固然是人寫的。因此咱們在不少項目裏都能見到相似 .eslintrc.json等相似的文件，這就是 ESLint 的配置文件。建議是初始化後一點一點修改這個配置文件，不要照抄Airbnb等等相似的規範，否則上來可能就報很是多的錯誤，一看就頭大。

安裝：

npm install --save-dev eslint 

// 若是項目使用了 React 須要再安一個 babel-eslint npm install --save-dev eslint babel-eslint 

ESLint 也能夠全局安裝，全局安裝後能夠方便用 ESLint 直接執行。

ESLint 初始化

ESLint 初始化能夠幫助開發者快速生成一個基本的配置框架。

在項目文件夾下執行

node_modules/.bin/eslint --init
// 若是全局安裝了 能夠直接 eslint --init 

這裏會給咱們三種方式來初始化ESlint

 

image

分別是 1. 問問題 2. 使用大廠的 3. 檢查現有的代碼自動生成

�咱們這裏直接選第一個，回答一些問題來肯定配置。

 

image

根據實際狀況回答就行了，即便不當心答錯也不要緊，都在配置文件裏隨時能夠修改。

 

image

部分同窗可能有疑惑關於line endings ，其實看一下編輯器下面，若是是 LF 選擇 Windows，CR 就選 Linux 就行了 。這個關於windows和linux對換行符的定義不一樣致使的，有興趣的同窗能夠本身搜搜。

 

image

生成的.eslintrc.json 根據選擇的回答不一樣，大致都長這樣

{
    "env": { "browser": true, "commonjs": true, "es6": true }, "extends": "eslint:recommended", "parserOptions": { "ecmaFeatures": { "experimentalObjectRestSpread": true, "jsx": true }, "sourceType": "module" }, "plugins": [ "react" ], "rules": { "indent": [ "error", 4 ], "linebreak-style": [ "error", "windows" ], "quotes": [ "error", "single" ], "semi": [ "error", "always" ] } } 

ESLint 配置解釋：

env: Environments，指定代碼的運行環境。不一樣的運行環境，全局變量不同，指明運行環境這樣ESLint就能識別特定的全局變量。同時也會開啓對應環境的語法支持，例如：es6。

parser：ESLint 默認使用Espree做爲其解析器，但它並不能很好的適應 React 環境，因此剛纔安裝了 babel-eslint 用來代替默認的解析器，在配置裏這麼寫"parser": "babel-eslint"。

plugins：顧名思義就是插件，插件是單獨的npm包，命名通常以eslint-plugin開頭，寫的時候用字符串數組的形式，能夠省略eslint-plugin開頭。plugins通常包含一個或多個規則配置，能夠在extends中引入。

extends：ESLint 不須要自行定義大量的規則，由於不少規則已被分組做爲一個規則配置。

例如：eslint:recommended就是 ESLint 的推薦規則配置，包含了ESLint的規則 裏前面有✔︎的部分，recommended 規則只在ESLint升級大版本的纔有可能改變。

相對的 eslint:all 是應用全部的規則，但並不推薦這麼作。另外，all 規則是根據版本隨時變化的。
extends 還能夠以字符串數組的形式定義。

"extends": ["eslint:recommended", "plugin:react/recommended"], 

plugin:react/recommended 即爲 eslint-plugin-react 插件中的提供的推薦規則配置。

另外還有一點，extends定義的規則若是有重複的，後面的規則會覆蓋前面的。

rules：這裏能夠對規則進行細緻的定義了，覆蓋以前前面說的extends中定義的規則。例如 indent就是對縮進的修改。"indent": ["error",4] 前面一項表明錯誤等級，第二項是具體配置，有些規則有第三項選項，例如 indent 就有 { "SwitchCase": 1 }，表明對switch語句採起什麼樣的縮進策略，若是不設默認是0。具體能夠定義什麼 rules，能夠參考這裏

錯誤等級有三級 0，1，2，分別表明off，warning，error。error錯誤會終止 lint-staged 執行。

globals：全局變量，若是你的項目用到其餘一些自定義的全局變量，"__DEV__": false這樣配置，true
和 false 表明可不能夠被修改。

其餘可用的配置參考這個

React Native 項目的配置例子

{
  "parser": "babel-eslint", "env": { "commonjs": true, "es6": true, "react-native/react-native": true }, "extends": [ "eslint:recommended", "plugin:react/recommended", ], "parserOptions": { "ecmaFeatures": { "experimentalObjectRestSpread": true, "jsx": true }, "sourceType": "module" }, "plugins": [ "react", "react-native", ], "rules": { "no-unused-vars": 1, "react/prop-types": 1, "react/display-name": 0, } } 

~後面跟了一堆是全局變量，沒有使用 react-native 的 config 是由於到目前還不適配 ESLint 4版本。~
eslint-plugin-react-native已經更新了，這樣配置又簡潔了一些。

調試配置

配置確定是不能拿來就用的，推薦先就只使用 eslint:recommended 版本，若是你的項目 indent 比較特殊，再到 rules 定義 indent 就能夠了。

而後先用命令行命令先對代碼庫裏比較典型文件測試一下

node_modules/.bin/eslint app/app.js --fix

加上 --fix 會自動修復一些問題，規則列表裏前面有小扳手的是能夠自動修復的。

 

image

不用擔憂，一開始確定特別多。根據報錯信息最後的規則名稱，搜索搞清楚究竟是爲何錯，看這個錯誤對於你的項目庫是什麼程度，再到rules裏去自定義這條規則。

處理好這一步，就完成部署 commit 自動處理代碼的流程了。若是代碼沒有經過 ESLint 檢查，就會出現這種通知，中止commit。

Webstorm

 

Webstorm

Terminal

 

image

Webstorm 插件

從前面看出 Webstorm的通知是不太友好的，咱們能夠用Webstorm的配置，方便更快的找到錯誤的發生點（但不是必須的）。

內置了ESlint工具

Webstorm 內置了ESlint工具，啓動以後能夠在編輯的時候就能看到哪裏出錯須要修復。

 

image

選好 Node 環境路徑和 ESLint 包路徑，勾線Enable就行了，會自動尋找ESLint的配置。
ESlint 路徑：~/Documents/{Your Project}/node_modules/eslint

還能夠在快捷鍵設置裏給 Fix ESLint Problem 添加一個快捷鍵，快速進行代碼格式化的操做。

 

image

我的感受在檢查代碼出錯的時候比較好用，但在實際寫代碼的時候我我的仍是傾向於不開這個來寫，常常看到報錯信息，使人心情很差。

External Tools

我更傾向於本身寫一個 External Tools ，方便對當前文件執行命令，在提交以前或者提交報錯以後跑一遍，有詳細的報錯清單，找起來也很方便（但沒打開ESLint設置看起來更直觀）。

 

image

下面三項填入

node_modules/.bin/eslint
--fix $FilePathRelativeToProjectRoot$
$ProjectFileDir$

External Tools 能夠設置快捷鍵，也能夠經過 Webstorm 的命令面板搜索打開 cmd + shift + a。

 

image

 

image

 

 

 

 https://www.jianshu.com/p/cdd749c624d9?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation