前端大厂项目协同合作代码规范，git commit规范（约定式提交）

Eslint+Prettier代码格式规范

vscode安装插件

https://www.prettier.cn/

在项目根目录中新建.prettierrc文件

{
    "semi": false, //是否尾随分号
    "singleQuote": true, //是否使用单引号去代替双引号
    "trailingComma": "none" //最后一行是否需要逗号  
}

vscode设置中 添加自动格式化代码 

 添加编辑器失去焦点自动保存代码 

 

添加一个tab默认占位2个字符

如果有多个代码格式化插件，在代码中右键 使用...格式化文档，选中prettier

解决Eslint和prettier冲突问题，去到eslint配置文件，加上保存的key值：”space-before-function-paren“设置为off

rules: {
    'space-before-function-paren': 'off'
}

git commit 规范（cz-customizable）

https://www.conventionalcommits.org/zh-hans/v1.0.0/

全局安装npm i -g commitizen@4.2.4

npm i -g commitizen@4.2.4

个人全局包

项目中安装npm i cz-customizable@6.3.0 -D 

npm i cz-customizable@6.3.0 -D 

项目根目录添加.cz-config.js文件，加上如下配置项

module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

 然后就可以在我们终端上选择本次提交的功能选项了，到下图为止我们就完成了本地代码的提交了

 最后将我们提交的内容推送到远程代码仓库

git push -u origin master

提交代码前校验是否遵循了代码提交规范（commitlint + husky）

但到这一步为止 在公司多人合作开发中如果有人不遵守你定义的这个代码提交规范呢？

这个时候我们就需要在代码提交前去判断程序员提交前的操作了 去校验我们提交的信息

这里我们用到了两个小工具

commitlint

husky

注意在安装这两个工具前需要保证你的npm版本大于7，若没有请自行更新

安装依赖

npm i  -S @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4

终端执行以下指令

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

进行刚刚执行指令创建的文件 修改配置

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
        //当前验证的错误级别
      2,
        //在上面情况下进行验证
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

保存时注意刚刚修改的配置文件必须以utf-8进行保存

安装husky

npm i husky@7.0.1 -S

执行生产husky文件夹

npx husky install

执行指令

npm set-script prepare "husky install"

运行prepare 执行成功

npm run prepare

两个工具相互配合 执行以下指令

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'

 

 这个时候我们还是用无规范化的提交方式提交我们的代码 可以发现报错无法执行提交了

到此为止 我们的企业级git commit强制代码提交规范就完成了

校验项目代码中代码格式规范

以上第一点中我们用了eslint+pre进行了代码格式规范，但假如你团队的成员不进行代码规范就提交代码呢？

npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"

 

 然后去设置中关闭我们的自动保存测试一下

 可以发现代码格式不规范就不给提交了

自动修复格式错误（lint-staged）

比如

1.我们只修改了个别的文件，没有必要检测所有的文件代码格式

2.它只能给我们提示出对应的错误，我们还需要手动的进行代码修改

lint-staged 可以让你当前的代码检查 只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送

lint-staged 无需单独安装，我们生成项目时，vue-cli 已经帮助我们安装过了，所以我们直接使用就可以了

修改package.json

"lint-staged": {
    "src/**/*.{js,vue}": [
      "eslint --fix",
      "git add"
    ]
  },

修改pre-commit

npx lint-staged

再次测试双引号提交

自动修改为单引号了

最后执行提交

git push -u origin master