Lint Your Code

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

Lint JS

我们使用ESlint对JS进行代码规范。

1. 安装

你可以全局安装:npm install eslint -g

或者也可以在你的项目安装 npm install eslint --save-dev

安装完成后,可在命令行检查你的代码是否符合规范。如果是全局安装则可以使用 eslint your-file 检查你的文件。如果是项目内安装则使用:./node_modules/.bin/eslint your-file

2. 配置

通过eslint --init命令可以生成一个配置文件。你也可以自己创建.eslintrc.*文件,或者在package.json中通过eslintConfig配置。在这里我们使用.eslintrc文件进行配置。当你使用eslint命令检查你的代码时,它会从当前目录开始一层层向上查找是否存在.eslintrc文件,直到找到最近的一个.eslinrc文件,作为此次检查的规则。

你可以在ESLint官网查看所有配置项。

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

以我目前使用的Airbnb的代码规范为例,他提供了eslint-config-airbnb-base插件,因此我只需要在项目安装本插件:

npx install-peerdeps --save-dev eslint-config-airbnb-base

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

{
  "extends": ["airbnb-base"]
}

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

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

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

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

"overrides": [
    {
      "files": ["*-test.js","*.spec.js"],
      "rules": {
        "no-unused-expressions": "off"
      }
    }
  ]

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

安装完成后,如果是全局安装则可以使用 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:

npm install stylelint-config-airbnb

在配置文件中声明:

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

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

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

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

同样,你也可以像ESLint一样,通过rules配置你自己的规则。

3. 禁用

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

Lint Commit

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

  • 检查前2步的ESLintstylelint 是否全部通过;
  • 提交的commit信息是否符合规范。

OK, Let’s do it!

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

我们使用husky来管理我们的githooks。在安装husky之前,请确保你的项目已经git init了。

安装husky:npm install husky --save-dev

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",
    }
  }
}

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

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

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

2. 使用commintlint检查 commit 信息是否符合规范

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

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中,type 可选项为:

feat:新功能(feature)

fix:修补bug

docs:文档(documentation)

style: 格式(不影响代码运行的变动)

refactor:重构(即不是新增功能,也不是修改bug的代码变动)

test:增加测试

chore:构建过程或辅助工具的变动

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

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

生成配置文件:

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

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

Configuration is picked up from commitlint.config.js, .commitlintrc.js, .commitlintrc.json, or .commitlintrc.yml file or a commitlint field in package.json

并且常用的配置项也与ESLint很相似:

  {
      "extends": ['@commitlint/config-conventional'], // 扩展的规则集
      "rules": {
          // commitmsg 的自定义规则
      }
  }

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

echo "foo" | npx commitlint 

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

{
    "scripts": {
        "commitmsg": "commitlint -e GIT_PARAMS"
    },
    "husky": {
    "hooks": {
      "pre-commit": "npm run lint:all",
      "commit-msg": "npm run commitmsg"
    }
  }
}

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

3. 使用commitizen来填写commit msg

要想记住所有的commit类型和规范也是比较麻烦的事,commitizen提供交互式的方式来帮助我们填写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,会出现一个交互式工具:

    《Lint Your Code》

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

git add .
git cz

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

总结

    原文作者:Yawenina
    原文地址: https://segmentfault.com/a/1190000015804468
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞