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

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

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
husky对应的node版本
(2)lint-staged 13.2.2 要求的 Node 版本是 ^14.13.1 || >=16.0.0

在这里插入图片描述

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

3、安装IDE插件,必要的有:

关于团队代码规范化Husky+Lint-staged+ESLint+Prettier_第1张图片
关于团队代码规范化Husky+Lint-staged+ESLint+Prettier_第2张图片

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

二:编写关键代码

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 查找相对应的解决方法。

关于团队代码规范化Husky+Lint-staged+ESLint+Prettier_第3张图片

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

eslint错误提示

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的文件如图所示:

关于团队代码规范化Husky+Lint-staged+ESLint+Prettier_第4张图片

再然后执行

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

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

关于团队代码规范化Husky+Lint-staged+ESLint+Prettier_第5张图片

三:看效果(git commit -m ‘xxxx’ 时生效)

关于团队代码规范化Husky+Lint-staged+ESLint+Prettier_第6张图片
我是在更改了一个文件并且add之后执行了commit操作,然后终端就输出了上述代码格式化过程。

至此,就规范化的 愉快的 搬砖啦!

你可能感兴趣的:(规范化,代码规范,前端)