背景

多集体做一个我的项目的时候，总是因为大家代码格调不对立，须要通过文档约定的形式来对立格调。

比方文件起名形式，有的人首字母大写，有的人首字母小写，在js,ts,vue中又有这种迥异的格调。针对这种状况，咱们起了个约定文档，规定应该怎么给文件夹命名，然而这种有个毛病就是，无奈从本源上解决，也就是新来的共事可能不晓得这个规定，而后就新建了一个非约定的文件名。

除了文件名，提交标准也是迥异的，有的人commit的时候不加type，这种咱们也是起了个约定文档。

缓缓的文件目录就多了个docs

文档是有益处的，然而也无奈从本源上限度问题。所以当初的前端我的项目，引出了工作流理念，也多了很多定制工作流的辅助工具。

工作流概览

多人的我的项目，总是须要规定一些标准，为了让代码格调尽量对立。咱们须要用到以下工具：

  • 代码丑化 - prettier
  • 语法标准 - airbnb
  • 语法校验 - eslint
  • git-hook - husky
  • 提交标准 - commitlint
  • 文件命名标准 - ls-lint
  • 主动修复代码 - lint-staged

eslint & prettier

这里有一篇写得比拟好的文章，这里就不开展讲怎么配置了。

commitlint 代码提交标准

commitlint 用来帮忙团队恪守提交标准，更多信息可查看官网

装置

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

格局

[type]: [subject]

  1. type为以下字段

    • feat：新性能（feature）
    • fix：修补bug
    • docs：文档（documentation）
    • style： 格局（不影响代码运行的变动）
    • refactor：重构（即不是新增性能，也不是批改bug的代码变动）
    • test：减少测试
    • chore：构建过程或辅助工具的变动
    • upd: 更新功能模块
    • workflow: 工作流变动
  2. subject为形容内容，比方
    修复设施日志色彩值转换的问题

  3. 残缺的形容，⚠️ 留神冒号后带空格，比方

    git commit -m 'fix: 修复设施日志色彩值转换的问题'git commit -m 'chore: 批改commitlint配置文件'

commitlint.config.js

commitlint反对终端输出指令的模式执行校验，当然也反对配置文件的模式。
配置文件的具体内容如下：

rulers字段，由name和配置数组组合，配置数组包含：

  • Level[0,1,2]: 0示意禁用规定，1会被视为正告，2抛出异样
  • Applicable always|never: 是否利用规定
  • Value: 改规定利用的值

配置数组能够是：数组，返回数组的函数，返回数组的promise。

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

配置git-hook

githook其实就是你在git操作时的回调。这里咱们只关怀一个git-hook就是pre-commit，提交前的回调。

通过对commitlint的配置，咱们曾经对提交标准做了配置，然而咱们遇到了一个问题，什么时候才应该去校验提交的标准。

从commitlint官网中咱们理解到，咱们须要装置husky，该插件可能通过简略的配置，执行githook。

husky & yorkie

帮忙咱们可能间接在package.json配置git-hook.

husky在package.json配置内容如下

"husky": {    "hooks": {      'commit-msg': 'commitlint -E HUSKY_GIT_PARAMS',     }  }

如果咱们是通过vue的脚手架（vue-cli）搭建的我的项目，其实外部用了yorkie，yorkie是尤雨溪fork了husky之后做了小批改.
所以此时的package.json你能够这么配置

"gitHooks": {        "commit-msg": "commitlint -e $GIT_PARAMS" },

留神两个配置传递给 -e 的参数不同，一个是HUSKY_GIT_PARAMS， 一个是GIT_PARAMS。
其实husky以前也是GIT_PARAMS，只是起初降级到v1.0.1版本当前改为HUSKY_GIT_PARAMS。

lint-staged

有个commit的githook，那是不是也能做一些代码格局丑化，修复eslint问题的工作。lint-staged就是干这个的。

应用到lint-staged工具来辨认被退出到stage区文件,就是每次只对以后批改后的文件进行扫描，即只对git add退出到stage区的文件进行扫描即可，实现对增量代码进行查看。

装置lint-staged

npm i -D lint-staged

lint-staged的配置如下：

"lint-staged": {    "*.{js,jsx,vue,ts,tsx}": [        "vue-cli-service lint",        "git add"    ]}

ls-lint

在较大的我的项目中，咱们须要约定文件的命名格局标准。如下：

1.文件夹 & 文件采纳camelCase(小驼峰)，比方：text文件夹 ./layout/...文件名 iiapHeader.vue
ls-lint帮忙咱们主动校验文件命名标准，省去了约定的麻烦，咱们只须要在提交的时候，测验文件的命名标准即可

在npm中退出如下命令

"scripts": {    "ls-lint": "ls-lint"},

.ls-lint.yml文件配置如下：

ls:    .vue: PascalCase    .js: kebab-case    .config.js: lowercase    .ts: camelCase | PascalCase    .d.ts: camelCase | kebab-case    .spec.ts: camelCase | PascalCase    .mock.ts: camelCase    .vdom.js: kebab-case    .spec.js: kebab-caseignore:    - dist    - test    - .babelrc.js    - .eslintrc.js    - .prettierrc    - .github    - .git    - node_modules

残缺的配置

所以咱们整个workflow集成:
代码格调对立 -> eslint优化 -> 文件命名标准 -> 提交标准

咱们别离创立:

  • .ls-lint.yml
  • commitlint.config.js

package.json配置:

"scripts": {    "ls-lint": "ls-lint"},"gitHooks": {    "pre-commit": "ls-lint && lint-staged",    "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"},"lint-staged": {    "*.{js,jsx,vue,ts,tsx}": [        "vue-cli-service lint",        "git add"    ]}