郭雁宏的博客

# 项目开发中的规范

形成良好统一的代码规范，有利于提高代码的可读性，减少潜在的错误，便于团队写作开发。本问简单介绍JS、CSS、Git Commit的规范工具和用法。

# Lint JS

我们使用Eslint (opens new window)

# 1. 安装

你可以全局安装

npm install eslint -g
1

或者也可以在你的项目安装

npm install eslint --save-dev
1

安装完成后，可在命令行检查下你的代码是否否和规范。如果是全局安装则可以使用

eslint your-file
1

# 2. 配置

通过eslint --init命令可以生成一个配置文件。你也可以自己穿件.eslintrc.*文件，或者使用eslint命令检查你的代码时，它会从当前目录开始一层层向上查找是否存在.eslintrc文件，直到找到最近的一个.eslintrc文件，做诶此次检查的规则。

你可以在Eslint (opens new window)官网查看所有配置项

目前已经有很多大厂公开了他们的代码规范，也有很多相对应的Eslint插件，我们可以在.eslintrc中配置相对应的插件，这样就不用我们动手去添加一个个规则了。

以我们目前使用的Airbnb的代码规范为例，他提供了eslint-config-airbnb-base (opens new window)插件，因此我只需要在项目安装本插件：

npx install-peerdeps --save-dev eslint-config-airbnb-base
or
npm install --save-dev eslint-config-airbnb-base
1
2
3

并且在.eslintrc中配置上这个插件，大功告成！

{
  "extends": ["airbnb-base"]
}
1
2
3

需要⚠️的一点是，如果你是使用全局命令eslint你的代码，在相应的.eslintrc中的extends，plugins都需要在全局安装。否则eslint会找不到相对应的插件。

最后，如果你还想对现有的airbnb或者现有其他规则进行配置，则可以在.eslintrc中的rules加上相应的配置。

{
  "extends": ["airbnb-base"],
  "rules": {
    // 你的个性化配置
        "rule-name": "" // 0-off, 1-warn, 2-error
  }
}
1
2
3
4
5
6
7
8

还有一个比较例外的是可以使用以下方式，针对某些文件，重新修改相应规则：

"overrides": [
    {
      "files": ["*-test.js","*.spec.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]
1
2
3
4
5
6
7
8

# 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
1

安装完成后，如果是全局安装则可以使用 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 (opens new window)：

npm install stylelint-config-airbnb
1

在配置文件中声明：

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

注意，如果你的.stylelintrc文件是在根目录下，则extends的路径需要写成绝对路径，比如：

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

最后，运行stylelint your-css-file就可以出现规范检查结果啦！stylelint默认会支持css,scss,less所以你也不用担心哦~

# 禁用

stylelint 的规则也和 ESLint一样。所以如果熟悉了ESLint， stylelint真的可是说是无缝上手哦~

# Lint Commit

在这一步我会进行两步操作：

  • 检查前2步的ESLint，stylelint 是否全部通过；
  • 提交的commit信息是否符合规范。

# 1. 使用githooks检查代码规范是否通过

我们使用husky (opens new window)来管理我们的githooks。在安装husky之前，请确保你的项目已经git init了。

安装

husky:npm install husky --save-dev
1

在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",
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

在这里我们分别定义了lint:es和lint:css两个命令来检测代码规范。你可以分别运行这两个命令。也可以定义一个命令同时运行这两个命令，我在这里使用了npm-run-all：

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

我们定义了在pre-commit钩子触发时会执行npm run lint:all命令。pre-commit钩子会在git commit时触发，如果lint:all没有通过，则本次commit会失败。

# 2. 使用commintlint (opens new window)检查 commit 信息是否符合规范

官网 (opens new window)

在这里，我们使用阮老师这篇文章中提到的 git 提交规范， 大致是：

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
1
2
3
4
5

其中，type 可选项为：

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
1
2
3
4
5
6
7

安装commitlint， 以及相对应的commit规范。和eslint一样，commitlint为我们提供检测功能，同时他也有不同的插件来对应不同的规范风格。你可以在这里查看大家分享出来的相应规范的配置。

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

生成配置文件：

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

它也支持多种文件格式的配置文件:

Configuration is picked up from
commitlint.config.js,
.commitlintrc.js,
.commitlintrc.json,
 or
.commitlintrc.yml file
or
a commitlint field in package.json
1
2
3
4
5
6
7
8

并且常用的配置项也与ESlint很相似：

  {
      "extends": ['@commitlint/config-conventional'], // 扩展的规则集
      "rules": {
          // commitmsg 的自定义规则
      }
  }
1
2
3
4
5
6
7

这时候你就可以检查你要提交的commit信息是否符合规范了：

echo "foo" | npx commitlint
1

不过这样很鸡肋，我要先commit一次要提交的信息，通过了，再用这条消息提交一次。我们完全可以在githooks时来解决这个问题：

{
    "scripts": {
        "commitmsg": "commitlint -e GIT_PARAMS"
    },
    "husky": {
    "hooks": {
      "pre-commit": "npm run lint:all",
      "commit-msg": "npm run commitmsg"
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12

在这里和githooks同时使用时需要加上GIT_PARAMS这个环境变量。我们在commit-msg这个钩子时调用npm run commitmsg 来判断commit信息是否符合规范。

# 3. 使用commitizen (opens new window)来填写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，会出现一个交互式工具：

OK。完成以上三步之后我们的git 工作流变成了：

git add .
git cz
1
2

然后就会检查我们的eslint, stylelint, commitlint。这样，当你提交成功时，你的JS, CSS , Commit Msg 也是完全符合规范的哦~