代碼規範篇——各種lint

一、eslint

ESLint 是在 ECMAScript/JavaScript 代碼中識別和報告模式匹配的工具，它的目標是保證代碼的一致性和避免錯誤。這是官網地址 https://eslint.bootcss.com/docs/user-guide/getting-started

• ESLint 使用 Espree 解析 JavaScript。
• ESLint 使用 AST 去分析代碼中的模式
• ESLint 是完全插件化的。每一個規則都是一個插件並且你可以在運行時添加更多的規則。

首先安裝一下 eslint 模塊

npm i eslint -D

再初始化 eslint 配置，執行 --init 命令會在項目根目錄下自動創建 .eslintrc.js 配置文件。期間會提供一些選項讓你選擇，你的模塊標準是 ES6 還是 CommonJs、項目中用的是 react 還是 vue 等，然後根據你的選擇豐富配置信息。當然你也可以手動創建

下面是默認生成的配置文件 .eslintrc.js

module.exports = {
    "env": {
        "browser": true,
        "commonjs": true,
        "es6": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        'standard' // 這行是自己加的，代碼規範庫
    ],
    "globals": {
        "Atomics": "readonly",
        "SharedArrayBuffer": "readonly"
    },
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 2018
    },
    "plugins": [
        "react"
    ],
    "rules": {
        // 可以自己定義一些規則
    }
};

1.1 編碼規範

應用了 ESLint 後，通常是需要自己來配置繁雜的 rules 規則，這也是一個喜好類的東西，多數人是不願意在這上面耗費太多精力的（比如手動配置數百個ESLint 規則），於是github 上出現了一些開源的代碼規範庫，比較流行的有 airbnb、standard、prettier等

1.2 使用

--ext 格式檢查

在 .eslintrc.js 同級目錄下執行  eslint src/ --ext .js，意思是檢查 src 目錄下所有的 js 文件內容規範，如果代碼風格不符合規範，給給出警告或者錯誤提示

--fix 自動修復

我們執行 --fix 命令，eslint 會按照我們定製的格式自動修復文件，然後我們再次執行格式檢查就不會有報錯了

結合 vscode，實現保存時自動修復格式，首先安裝一下ESLint 插件。

安裝好了之後默認設置已經可以實現保存時自動格式化了，如果不能，接着下面的設置

vscode 打開文件->首選項->設置，搜索 eslint

選中 Enable

打開 setting.json 文件

找到 source.fixAll.eslint 並設置爲 true，如此，當我們 ctrl + s 保存代碼時，就能實現代碼自動格式化

二、stylelint

2.1安裝

npm install -d -save-dev stylelint

安裝 stylint-config-standard 和 stylelint-order

npm install stylelint-config-standard stylelint-order --save-dev

其中，stylelint是運行工具，stylelint-config-standard是stylelint的推薦配置，stylelint-order是CSS屬性排序插件(先寫定位，再寫盒模型，再寫內容區樣式，最後寫 CSS3 相關屬性)。

2.2 使用

stylelint 配置文件可以寫成  .stylelintrc .stylelintrc.json , .stylelintrc.yaml , .stylelintrc.yml , .stylelintrc.js 都可以，爲了能和 .eslintrc.js 保持一致，我用的時 .stylelintrc.js。

module.exports = {
    processors: [],
    plugins: [],
    extends: "stylelint-config-standard", // 這是官方推薦的方式
    rules: {
      "at-rule-empty-line-before": "always"|"never",
      "at-rule-name-case": "lower"|"upper",
      "block-no-empty": true,
    }
};

 格式檢查

 --fix 自動修復

2.3 配合 vscode

首先安裝 stylelint 插件

三、prettier

eslint、stylelint 的關注點是語法檢查，它可以幫助你檢測出代碼中的潛在問題，提高代碼質量，甚至自動幫你修復問題（--fix）。但是並不能完全統一代碼風格。

而 prettier 專注於代碼風格，它能夠完全統一你和同事的代碼風格，提高代碼的可讀性。但是由於 eslint、stylelint 也會對代碼做一些格式化的操作，所以他們和 prettier 可能會出現一些衝突。它有一下幾個優點：

• 代碼規範比 ESLint 的 Airbnb、Standard 更好更先進。
•  比 ESLint 提供更少的代碼風格規則配置項，終極目的是結束關於代碼風格的爭論。
• 比 ESLint 支持更多的語言

3.1 安裝

npm i -D prettier eslint-plugin-prettier

eslint-plugin-prettier插件會調用prettier對你的代碼風格進行檢查，其原理是先使用prettier對你的代碼進行格式化，然後與格式化之前的代碼進行對比，如果過出現了不一致，這個地方就會被prettier進行標記。 

3.2 使用

//.eslintrc.js
{
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

prettier 默認的風格不能滿足我們，我們也可以自己做一些個性化的配置。在根目錄新建 .prettierrc.js

module.exports = {
  "printWidth": 80, //一行的字符數，如果超過會進行換行，默認爲80
  "tabWidth": 2, //一個tab代表幾個空格數，默認爲80
  "useTabs": false, //是否使用tab進行縮進，默認爲false，表示用空格進行縮減
  "singleQuote": false, //字符串是否使用單引號，默認爲false，使用雙引號
  "semi": true, //行位是否使用分號，默認爲true
  "trailingComma": "none", //是否使用尾逗號，有三個可選值"<none|es5|all>"
  "bracketSpacing": true, //對象大括號直接是否有空格，默認爲true，效果：{ foo: bar }
  "parser": "babylon" //代碼的解析引擎，默認爲babylon，與babel相同。
}

四、commitlint

現在我們已經可以通過 eslint、stylelint 來檢查本地代碼是否存在潛在錯誤，通過 prettier 來規範代碼風格。但是團隊裏就是有個刺兒頭，他把 vscode 中這插件的功能都給關了。然後把不符合規範的代碼提交到遠程倉庫，然後你和其他同事把代碼下載下來，恨恨的說了一句 mmp。

既然刺兒頭不按規範了約束代碼，我就讓你不能提交。

4.1 git hooks

git 可以在特定的動作發生時觸發自定義腳本。這些鉤子都被放在 .git/hooks 文件夾下，文件名都是以 .simple 結尾。如果你想啓用它，那麼把這個文件名後綴去掉就行了。

我們來看一下 commit msg 規範怎麼做。下面的規範僅供參考（type: message）

• feat：新功能（feature）
• fix：修補bug
• hotfix：緊急修復bug
• test：增加測試
• docs：文檔（documentation）
• style： 格式（不影響代碼運行的變動）
• refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
• chore：構建過程或輔助工具的變動

首先我們需要把 commit-msg 改爲 commit-msg.simple，這樣就啓用了這個鉤子

然後把內容改成這個樣子

#!/bin/bash
MSG=`awk '{printf("%s",$0)}' $1`
if [[ $MSG =~ ^(feat|fix|test|refactor|docs|style|chroe)\(.*\):.*$ ]]
then
	echo -e "\033[32m commit success! \033[0m"
else
    echo -e "\033[31m Error: the commit message is irregular \033[m"
	echo -e "\033[31m Error: type must be one of [feat,fix,docs,style,refactor,test,chore] \033[m"
    echo -e "\033[31m eg: feat(user): add the user login \033[m"
	exit 1
fi

這個時候我們在 commit 的時候，如果不符合規範，是無法提交的

只有符合規範的 message 纔可以提交

4.2 husky

husky能夠防止不規範代碼被commit、push、merge等等。

4.2.1 安裝

npm install husky --save-dev

 4.2.2 使用

在 package.json 中加入這麼一段配置

"husky": {
    "hooks": {
      "pre-commit": "eslint --ext .js,.vue src && git add ."
    }
 }

意思是在 commit 之前會先檢查 src 下的 js 和 vue 文件是否符合規範，如果不符合，那麼 commit 是不會成功的。如下

意思是我在 main.js 中定義了一個變量 Fingerprint，但是卻沒有使用它。現在我們把 main.s 中的這個沒用的變量給去掉

成功了，同理我們可以在 commit 之前加上對 css 的校驗。 

4.3 lint-staged

當我們在 pre-commit 中做很多事情的時候，上面那種寫法就比較蛋疼，會是老長老長的一串。這個時候我們就可以引入 lint-staged 來大理這些任務，具體配置如下

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

如此，當我們在執行 commit 的時候，會先去執行 lint-staged 中的代碼。

• 對 css 先進行語法檢查並修復，在格式化代碼風格，在 git add 到緩存中
• 對 scss 同上
• 對 js 同上

這樣任務看起來就清晰多了