1.lint-stage+husky

npm install --save-dev lint-staged husky

配置：可在.huskyrc.js  或者package.json

https://www.npmjs.com/package/husky

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx}": [
      "prettier --write",
      "eslint --fix",
      "git add"
    ],
    "*.{css,md}": [
      "prettier --write",
      "git add"
    ]
  },

lint-staged是一个可以提供运行脚本校验文件的插件平台；可以根据不同文件执行不同的命令(Lint-staged，一个仅仅过滤出Git代码暂存区文件(被committed的文件)的工具,并不像eslint那样需要配置忽略配置

；配置内的文件全量遍历检查)

https://github.com/okonet/lint-staged#readme

执行命令若有需要用到环境变量；用cross-env插件添加

Use environment variables with linting commands
Linting commands do not support the shell convention of expanding environment variables. To enable the convention yourself, use a tool like cross-env.

For example, here is jest running on all .js files with the NODE_ENV variable being set to "test":

{
  "*.js": ["cross-env NODE_ENV=test jest --bail --findRelatedTests"]
}

lint-staged使用style-lint

Stylelint for CSS with defaults and for SCSS with SCSS syntax
{
  "*.css": "stylelint",
  "*.scss": "stylelint --syntax=scss"
}
Run PostCSS sorting and Stylelint to check
{
  "*.scss": ["postcss --config path/to/your/config --replace", "stylelint"]
}

 

2.eslint:  extends(standard airbnb)
eslint:recommended这个是默认规则，https://eslint.org/docs/rules/ 上可以查recommended的有什么规则

例如debugger默认是不允许的

 

 

参考：https://www.cnblogs.com/jiaoshou/p/12250278.html  lint-staged

 

3.commitlint  

https://github.com/commitizen/cz-cli

参考：https://www.cnblogs.com/jiaoshou/p/11190619.html

VSCode可以用 vscode-commitizen ,Open the command panel (ctrl+shift+p or command+shift+p) and type 'conventional commit'.

安装命令如下。

npm install --save-dev commitizen

初始化项目以使用cz-conventional-changelog适配器

npx commitizen init cz-conventional-changelog --save-dev --save-exact

安装完可以在script添加命令或者：npx git-cz

/**
 * feat：新增功能
 * fix：bug 修复
 * docs：文档更新
 * style：不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
 * refactor：重构代码(既没有新增功能，也没有修复 bug)
 * perf：性能, 体验优化
 * test：新增测试用例或是更新现有测试
 * build：主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
 * ci：主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
 * chore：不属于以上类型的其他类型，比如构建流程, 依赖管理
 * revert：回滚某个更早之前的提交
*/

强制使用commitizen

https://www.cnblogs.com/jiaoshou/p/11190619.html

Husky
For husky users, add the following configuration to the project's package.json:

"husky": {
  "hooks": {
    "prepare-commit-msg": "exec < /dev/tty && git cz --hook || true",  //限制不给直接用commit
　　 "commit-msg": "commitlint -E HUSKY_GIT_PARAMS,"  //commitlint检测  git commit -m '测试提交'时将触发commit-msg事件钩子
  }
}

使用commitlint校验(结合使用commitizen,husky)

npm install --save-dev @commitlint/cli @commitlint/config-conventional

commitlint.config.js里配置

module.exports = { extends: ['@commitlint/config-conventional'] };


module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      "feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"
    ]],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never']
  }
};

https://commitlint.js.org/#/

rule由name和配置数组组成，如： name:[0, 'always', 72] ，数组中第一位为 level ，可选 0,1,2 ，0为禁用规则，1为警告，2为错误，

第二位为应用与否，可选 always|never ，第三位该rule的值。 上面我们就完成了commitlint的安装与提交规范的制定。
检验commit message的最佳方式是结合git hook，所以需要配合Husky。