Vue + TypeScript 項目放棄 TSLint，擁抱 ESLint

背景

咱們的一些項目中用到了 TSLint 來規範咱們的 TypeScript 代碼，甚至沒有 Lint 工具來輔助開發，咱們這裏但願用 ESLint 來取代 TSLint，主要緣由是 TSLint 已經被官方放棄，因此咱們採用 ESLint，並結合 prettier 來規範咱們的代碼和統一團隊風格。

---

1、安裝 ESLint，刪除 TSLint

因爲咱們的項目可能不大同樣，有的項目是沒有任何 lint 工具，有的是 vue-cli 自帶安裝的 ESLint 或者 TSLint，這裏你們參考 package.json 文件，自行選擇。我如今以我手頭上的 shopintar 項目爲例，僅有 TSLint。

• 一、首先刪除 tslint.json 配置文件

• 二、安裝相關依賴

  npm i -d eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

  @typescript-eslint/parser: ESLint 專門解析 TypeScript 的解析器
  @typescript-eslint/eslint-plugin: 內置各類解析 TypeScript rules 插件
  

• 三、新建 .eslintrc.js 文件

module.exports = {
  root: true,
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  parser: 'vue-eslint-parser',
  extends: [
    'plugin:vue/recommended',
    'plugin:prettier/recommended',
    'prettier/@typescript-eslint',
    'plugin:@typescript-eslint/recommended',
  ],
  plugins: ['vue', '@typescript-eslint'],
  parserOptions: {
    parser: '@typescript-eslint/parser',
    sourceType: 'module',
    ecmaVersion: 2018,
  },
  rules: {
    'prettier/prettier': 'error',
    'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off',
    'space-before-function-paren': [2, 'never'], // function 的圓括號以前是否使用空格
    'array-bracket-spacing': 2,
    'no-var': 2,
    'no-eval': 2,
    'arrow-spacing': 2,
    'block-spacing': 2,
    'key-spacing': 2,
    'brace-style': 2,
    camelcase: 2,
    'comma-dangle': [2, 'always-multiline'],
    eqeqeq: [2, 'always', { null: 'ignore' }],
    'object-curly-spacing': [2, 'always'],
    'nonblock-statement-body-position': 2, // if 語句後必須跟大括號
    
    // 設置typescript-eslint規則
    // https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin/docs/rules
    '@typescript-eslint/member-delimiter-style': [
      2,
      {
        multiline: {
          delimiter: 'none', // 'none' or 'semi' or 'comma'
          requireLast: true,
        },
        singleline: {
          delimiter: 'semi', // 'semi' or 'comma'
          requireLast: false,
        },
      },
    ],
    '@typescript-eslint/interface-name-prefix': [2, { prefixWithI: 'always' }],
    '@typescript-eslint/explicit-function-return-type': ['off'],
    '@typescript-eslint/no-explicit-any': ["off"] // 先忽略，可是儘可能少用 any
  },
}

複製代碼

注意: parser: 'vue-eslint-parser'，這裏要區分和 parserOptions.parser 的區別，vue-eslint-parser 是解析 .vue 文件，而 parserOptions.parser：@typescript-eslint/parser 是咱們自定義來解析 TypeScript 的，不然就沒法正確的檢驗 TypeScript。相關解釋

2、安裝 prettier

prettier 用來作格式化工具配合咱們的 ESLint 能夠更大的發揮做用，首先安裝相關依賴：

npm i -g prettier eslint-config-prettier eslint-plugin-prettier

eslint-config-prettier: 這個插件的做用是當 ESLint 和 prettier 配置衝突時優先 prettier
eslint-plugin-prettier: 將 prettier 做爲 ESLint 規範來使用

接着按需配置 prettier，新建 .prettierrc 文件

{
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false,
  "semi": false,
  "trailingComma": "all",
  "printWidth": 120
}
複製代碼

而後在 .eslintrc.js 文件中引入 prettier 配置，在 extends 數組中添加 prettier/@typescript-eslint 和 plugin:prettier/recommended，到這裏 ESLint 和 prettier 相關配置已經完成，接下來咱們利用一些工具幫咱們在 git commit 階段完成代碼格式化和校驗工做。

3、使用 husky & lint-staged 自動完成校驗與格式化

• husky 是控制代碼提交的鉤子，在代碼被提交到Git倉庫以前，咱們能夠在這裏作一些預檢查或者格式化工做。
• lint-staged是一個前端文件過濾的工具（僅僅是文件過濾器），能夠對文件系統進行過濾，使得每次提交沒必要對全部文件進行校驗

1. 安裝husky 和 lint-staged

npm install husky lint-staged -D
複製代碼

2. 修改 package.json，增長配置：

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{ts,vue}": [
      "eslint --fix", "git add"
    ]
  }
複製代碼

上面配置，每次它只會在你本地 commit 以前，校驗你提交的內容是否符合你本地配置的 eslint規則，若是符合規則，則會提交成功。若是不符合它會自動執行 eslint —fix 嘗試幫你自動修復，若是修復成功則會幫你把修復好的代碼提交，若是失敗，則會提示你錯誤，讓你修好這個錯誤以後才能容許你提交代碼。

拓展： 除了在package.json中配置，也能夠在.lintstagedrc、lint-staged.config.js 文件中，lint-staged 的經常使用選項除了liners 以外，還有 ignore 、concurrent 等，具體參考文檔：

{
  "lint-staged": {
    "linters": {
      "*.{js,scss}": ["some command", "git add"]
    },
    "ignore": ["**/dist/*.min.js"]
  }
}
複製代碼

4、使用 Commitlint

Commitlint 能夠對代碼提交的信息進行規範和校驗，方便 團隊協做和快速定位問題

1. 安裝

npm install --save-dev @commitlint/config-conventional @commitlint/cli

// 生成配置文件commitlint.config.js，固然也能夠是 .commitlintrc.js
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

複製代碼

2. 配置

在husky的配置加入CommitlIint配置，」commit-msg": "commitlint -e $HUSKY_GIT_PARAMS」

husky: {
    hooks: {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },
複製代碼

3. 定製提交規範

• build: 影響構建系統或外部依賴關係的更改（示例範圍：gulp、broccoli、npm）
• ci: 對ci配置文件和腳本的更改（示例範圍：Circle、BrowserStack、SauceLabs）
• docs: 僅文檔更改
• feat: 新功能（feature）
• fix: 修補bug
• perf: 提升性能的代碼更改
• refactor: 重構（既不修復錯誤也不添加功能的代碼更改）
• style: 樣式修改，不影響代碼含義的更改
• test: 增長測試

例如：

git commit -m 'feat: 增長 xxx 功能'
git commit -m 'fix: 修復 xxx 功能'
複製代碼

Subject

Subject是 commit 目的的簡短描述，能夠作一些配置，如最大長度限制。

commitlint.config.js文件配置

rule配置說明 : rule由name和配置數組組成，如：’name:[0, ‘always’, 72]’，數組中第一位爲level，可選0,1,2，0爲disable，1爲warning，2爲error，第二位爲應用與否，可選always|never，第三位該rule的值。具體配置例子以下：

module.exports = {
  extends: [
    '@commitlint/config-conventional',
  ],
  rules: {
    'type-enum': [2, 'always', [
      'build', 'ci', 'docs', 'feat', 'fix', 'perf', 'refactor', 'style', 'revert',
    ]],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [0],
    'scope-case': [0],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never'],
    'header-max-length': [0, 'always', 72],
  },
}
複製代碼

總結

經過以上幾步咱們能夠在 commit 以前自動幫咱們完成格式化和校驗的工做，可是值得注意的是，這裏的格式化和校驗並非全局的，而是咱們當前提交的內容，若是咱們想要格式化全局代碼或者校驗全局代碼，這裏咱們能夠在 package.json 中的 script 命令中寫個腳本須要的時候手動執行一下，而不是把它放在 pre-commit 鉤子上每次 commit 都執行，耗費時間。

"format": "prettier --write \"src/**/*.ts\" \"src/**/*.vue\"",

"lint": "eslint --fix \"src/**/*.ts\" \"src/**/*.vue\""
複製代碼