关于团队代码规范化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操作，然后终端就输出了上述代码格式化过程。

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

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！