Lint Your Code

時間 2019-11-06

標籤 lint code 简体版

原文原文鏈接

造成良好統一的代碼規範，有利於提升代碼的可讀性，減小潛在的錯誤，便於團隊協做開發。本文簡單介紹JS、CSS、 Git Commit 的規範工具及用法。css

Lint JS

咱們使用ESlint對JS進行代碼規範。node

1. 安裝

你能夠全局安裝：npm install eslint -ggit

或者也能夠在你的項目安裝 npm install eslint --save-devexpress

安裝完成後，可在命令行檢查你的代碼是否符合規範。若是是全局安裝則可使用 eslint your-file 檢查你的文件。若是是項目內安裝則使用：./node_modules/.bin/eslint your-file。npm

2. 配置

經過eslint --init命令能夠生成一個配置文件。你也能夠本身建立.eslintrc.*文件，或者在package.json中經過eslintConfig配置。在這裏咱們使用.eslintrc文件進行配置。當你使用eslint命令檢查你的代碼時，它會從當前目錄開始一層層向上查找是否存在.eslintrc文件，直到找到最近的一個.eslinrc文件，做爲這次檢查的規則。json

你能夠在ESLint官網查看全部配置項。less

目前已經有不少大廠公開了他們的代碼規範，也有不少相對應的 ESLint 插件，咱們能夠在.eslintrc中配置相對應的插件，這樣就不用咱們手動去添加一個個規則了。ide

以我目前使用的Airbnb的代碼規範爲例，他提供了eslint-config-airbnb-base插件，所以我只須要在項目安裝本插件：工具

npx install-peerdeps --save-dev eslint-config-airbnb-base測試

而且在.eslintrc中配置上這個插件，大功告成！

{
  "extends": ["airbnb-base"]
}

須要注意的一點是，若是你是使用全局命令eslint你的代碼，在相應的.eslintrc中的extends，plugins都須要在全局安裝。不然eslint會找不到對應的插件。

最後，若是你還想對現有的 airbnb 或者其餘規則進行配置，則可在.eslintrc中的rules中加上相應的配置。

{
  "extends": ["airbnb-base"],
  "rules": {
    // 你的個性化配置
        "rule-name": "" // 0-off, 1-warn, 2-error
  }
}

還有一個比較例外的是可使用如下方式，針對某些文件，從新修改相應規則：

"overrides": [
    {
      "files": ["*-test.js","*.spec.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]

3. 禁用

可是有些時候有些地方你可能真的須要禁用某些規則，eslint提供了幾種禁用方式：

/* eslint-disable [rules] */：這行以後的全部代碼禁用eslint 規則。
/* eslint-disable-line [rules] */: 這一行禁用eslint規則。
/* eslint-disable-next-line [rules] */: 下一行禁用eslint規則。

其中[rules] 是可選的，若是沒有rules則禁用全部規則，若是有rules則禁用全部規則。

如 /* eslint-disable */則會禁用掉全部規則，/* eslint-disable no-console*/ 則只會禁用掉no-console 這條規則。

Lint CSS

我選擇了StyleLint來規範個人 CSS 。它能夠說和eslint很是像了。

1. 安裝

一樣的，全局或者項目下安裝stylelint.

npm install stylelint -g

安裝完成後，若是是全局安裝則可使用 stylelint your-css-file 檢查你的文件。若是是項目內安裝則使用：./node_modules/.bin/stylelint your-css-file。

2. 配置

能夠經過三種方式對stylelint進行配置：

package.json中的stylelint屬性；
.stylelintrc 文件
stylelint.config.js 文件導出一個 JS 對象

和 ESLint同樣，咱們能夠在extends中指定第三方插件，rules來配置對應的規則。這裏咱們仍是繼續使用Airbnb CSS 規範。

安裝stylelint-config-airbnb:

npm install stylelint-config-airbnb

在配置文件中聲明：

{  "extends": "stylelint-config-airbnb"}

注意，若是你的.stylelintrc文件是在根目錄下，則extends的路徑須要寫成絕對路徑，好比：

{
  "extends": "/usr/local/lib/node_modules/stylelint-config-airbnb"
}

最後，運行stylelint your-css-file就能夠出現規範檢查結果啦！stylelint默認會支持css,scss,less因此你也不用擔憂哦~

一樣，你也能夠像ESLint同樣，經過rules配置你本身的規則。

3. 禁用

stylelint 的規則也和 ESLint同樣。因此若是熟悉了ESLint， stylelint真的但是說是無縫上手哦~

Lint Commit

在這一步我會進行兩步操做：

檢查前2步的ESLint，stylelint 是否所有經過；
提交的commit信息是否符合規範。

OK, Let's do it!

1. 使用`githooks` 檢測代碼規範是否經過

咱們使用husky來管理咱們的githooks。在安裝husky以前，請確保你的項目已經git init了。

安裝husky:npm install husky --save-dev

在package.json中定義咱們須要的鉤子及執行的命令：

{
    "scripts": {
    "lint:es": "eslint", // lint js
    "lint:css": "stylelint src/**/*.css", // lint css
    "lint:all": "npm-run-all lint:es lint:css" // lint es, css
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm run lint:all",
    }
  }
}

在這裏咱們分別定義了lint:es和lint:css兩個命令來檢測代碼規範。你能夠分別運行這兩個命令。也能夠定義一個命令同時運行這兩個命令，我在這裏使用了npm-run-all：

npm install npm-run-all --save-dev

咱們定義了在pre-commit鉤子觸發時會執行npm run lint:all命令。pre-commit鉤子會在git commit時觸發，若是lint:all 沒有經過，則本次commit會失敗。

2. 使用commintlint檢查 `commit` 信息是否符合規範

在這裏，咱們使用阮老師這篇文章中提到的 git 提交規範，大體是：

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，type 可選項爲：

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

安裝commitlint，以及相對應的commit規範。和eslint同樣，commitlint爲咱們提供檢測功能，同時他也有不一樣的插件來對應不一樣的規範風格。你能夠在這裏查看你們分享出來的相應規範的配置。

npm install --save-dev @commitlint/{config-conventional,cli}

生成配置文件：

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

它也支持多種文件格式的配置文件：

Configuration is picked up from commitlint.config.js, .commitlintrc.js, .commitlintrc.json, or .commitlintrc.yml file or a commitlint field in package.json

而且經常使用的配置項也與ESLint很類似：

{
      "extends": ['@commitlint/config-conventional'], // 擴展的規則集
      "rules": {
          // commitmsg 的自定義規則
      }
  }

這時候你就能夠檢查你要提交的commit信息是否符合規範了：

echo "foo" | npx commitlint

不過這樣很雞肋，我要先commit一次要提交的信息，經過了，再用這條消息提交一次。咱們徹底能夠在githooks時來解決這個問題：

{
    "scripts": {
        "commitmsg": "commitlint -e GIT_PARAMS"
    },
    "husky": {
    "hooks": {
      "pre-commit": "npm run lint:all",
      "commit-msg": "npm run commitmsg"
    }
  }
}

在這裏和githooks同時使用時須要加上GIT_PARAMS這個環境變量。咱們在commit-msg這個鉤子時調用npm run commitmsg 來判斷commit信息是否符合規範。

3. 使用commitizen來填寫`commit msg`

要想記住全部的commit類型和規範也是比較麻煩的事，commitizen提供交互式的方式來幫助咱們填寫commit msg。

安裝commitizen及其adapater : npm install -g commitizen cz-conventional-changelog
全局安裝adapater: echo '{ "path": "cz-conventional-changelog" }' > ~/.czr
安裝完成後，使用 git cz 代替 git commit -m 來填寫 commit msg，會出現一個交互式工具：