关于团队代码规范化Husky+Lint-staged+ESLint+Prettier

首先，先抛出来一个问题，即：为什么要进行团队代码规范化？
先说下痛点：
1、团队协作开发中，不同的开发er更改了同个文件，因为格式化配置不同，会导致很多代码行产生冲突，难解决；
2、团队成员进行Code Review时，因为不同的格式化风格，会出现不合时宜（逻辑并无变化）的代码更改提示，从而影响合并效率;

3、代码洁癖（代码强迫症），该换行不换行，该一行展示又换行了，标签闭合点也那么怪怪的…我们总有那么多的吐槽点…；
4、lalalala…上升到价值。那可不就是不符合我们大前端的规范化标准嘛。

那么，接下来我们就来解决这些痛点！说开整咱就开整~~~

一：不得不说的准备工作

1、技术栈、包及版本号

husky 8.0.3
lint-staged 13.2.2
eslint 8.9.0
prettier 2.5.1

yarn add husky -D
yarn add lint-staged -D
yarn add eslint -D
yarn add prettier -D

又或者是

npm install husky -D
npm install lint-staged -D
npm install eslint -D
npm install prettier -D

2、Node与包版本关系

（1）husky 8.0.3 要求的 Node 版本是 ^14.18.0 || ^16.14.0 || >=18.0.0

（2）lint-staged 13.2.2 要求的 Node 版本是 ^14.13.1 || >=16.0.0

若实在不想更改Node版本，也可进行忽略：yarn config set ignore-engines true

3、安装IDE插件，必要的有：

执行命令行一通安装，接下来…

二：编写关键代码

1、配置package.json文件（附上的注释仅供理解，复制代码后要删除）

  "husky": {
    "hooks": {       
      "pre-commit": "lint-staged"    // 声明Git中的pre-commit钩子的扫描范围--只扫描暂存区内的文件
    }
  },
  "lint-staged": {   // 配置 lint-staged的工作文件类型以及需要执行的指令
    "src/**/*.{html,js,ts,json,css,scss,md}": [
      "prettier --write",   // 自动执行格式化代码的指令
      "git add ."  // 格式化之后，暂存区文件中代码可能会发生改变。此时自动执行git add .
    ],
    "src/**/*.{js,ts}": [
      "eslint --fix"  // 对代码进行规范检查，并且自动修复
    ]
  }

针对上述代码中 git add . 尚有疑问的朋友可以在配置时删除该行，然后再次执行，就会明白这行代码存在的意义!

ps：如需要对项目中所有文件执行一次格式化，请在此文件内加上以下代码

"scripts": {
	"prettier:all": "prettier --config .prettierrc --check \"src/**/*.{html,js,ts,json,css,scss,md}\" --write"
 }

在需要的时候执行 yarn prettier:all

2、在根目录新建.eslintrc.json文件，并进行配置（附有注释）

{
  "env": {
    "browser": true,
    "es6": true
  },
  "extends": ["alloy", "alloy/typescript"],
  "globals": {
    "Atomics": "readonly",
    "SharedArrayBuffer": "readonly"
  },
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "sourceType": "module",
    "ecmaFeatures": {
      "modules": true
    },
    "ecmaVersion": 6
  },
  "plugins": ["@typescript-eslint"],
  "rules": {
    // "@typescript-eslint/consistent-type-assertions": [
    //   "error",
    //   {
    //     "assertionStyle": "as",
    //     "objectLiteralTypeAssertions": "allow-as-parameter"
    //   }
    // ],
    // "@typescript-eslint/explicit-member-accessibility": "off", // 显式成员可访问性
    // "@typescript-eslint/member-ordering": "off", // 成员排序
    // "complexity": "off", // 限制程序中允许的圈复杂度来降低代码复杂度
    // "max-nested-callbacks": ["error", 8], // 强制执行回调可以嵌套的最大深度以提高代码清晰度
    // "max-params": ["error", 18], // 强制执行函数定义中允许的最大参数数量。
    // "prefer-object-has-own": "off", // 禁止使用 Object.prototype.hasOwnProperty.call() 而更喜欢使用 Object.hasOwn()
    // "no-param-reassign": "off" // 不允许重新分配 function 参数
    // "no-case-declarations": "error" // 该规则不允许在 case/default 子句中使用词法声明
    // "@typescript-eslint/no-useless-constructor": "off"  // 禁止不必要的构造函数
    // "@typescript-eslint/no-invalid-this": "off",  // 禁止在 this 的值为 undefined 的上下文中使用 this
    // "no-return-assign": "off",  // 在 return 语句中不允许赋值运算符
    // "prefer-promise-reject-errors": "off",  // 要求使用 Error 对象作为 Promise 拒绝原因
    // "keyword-spacing": "error",  // 在关键字前后强制保持一致的间距
    // "no-multi-spaces": [
    //   "error",
    //   {
    //     "ignoreEOLComments": true
    //   }
    // ],  //禁止多个空格
  }
}

package.json文件中的指令 eslint --fix，其中 eslint 只会自动修复 .eslintrc.json 里对应的 rules。

上述文件中，有多个规则被注释。那是因为在实际开发过程中，既然团队是想真正的使用ESLint去约束代码，实现代码规范化，那么就最好严格按照ESLint的语法规则去编码。
若有需要可自行配置忽略某条规则或其它约束规则。

另外，上述文件中的规则配置也仅仅是ESLint语法规则里的冰山一角，在实际开发过程中，我们遇到ESLint错误提示时（如下图所示），可去 ESLint 中文文档、ESLint 英文文档、ESLint Github 查找相对应的解决方法。

针对上边的 == 语法 出现了波浪线，鼠标浮上去就会出现下述提示语，那么我们按照提示去修复解决就行啦！

3、在根目录新建.prettierrc 文件，并进行配置

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "proseWrap": "preserve",
  "arrowParens": "avoid",
  "bracketSpacing": true,
  "endOfLine": "auto",
  "htmlWhitespaceSensitivity": "css",
  "jsxBracketSameLine": false,
  "jsxSingleQuote": false,
  "trailingComma": "es5"
}

不同的团队可能需要不同的格式规范去约束，那么我们可以在 官方文档 中找到适合自己团队的项，然后写入配置文件中。

4、手动启用husky（因为我们安装的是较新版本husky 8+，所以需要手动启用）

npx husky install

执行完此命令，项目根目录会生成一个.husky的文件如图所示：

再然后执行

 npx husky add .husky/pre-commit "npx lint-staged"

此时，你就会看到多了一个pre-commit文件

三：看效果（git commit -m ‘xxxx’ 时生效）

我是在更改了一个文件并且add之后执行了commit操作，然后终端就输出了上述代码格式化过程。

至此，就规范化的 愉快的 搬砖啦！