前端工作流

chuxiaoguo

背景

多个人做一个项目的时候,总是因为大家代码风格不统一,需要通过文档约定的方式来统一风格。

比如文件起名方式,有的人首字母大写,有的人首字母小写,在js,ts,vue中又有这种迥异的风格。针对这种情况,我们起了个约定文档,规定应该怎么给文件夹命名,但是这种有个缺点就是,无法从根源上解决,也就是新来的同事可能不知道这个规则,然后就新建了一个非约定的文件名。

除了文件名,提交规范也是迥异的,有的人commit的时候不加type,这种我们也是起了个约定文档。

慢慢的文件目录就多了个docs
image.png
文档是有好处的,但是也无法从根源上限制问题。所以现在的前端项目,引出了工作流理念,也多了很多定制工作流的辅助工具。

工作流概览

多人的项目,总是需要规定一些规范,为了让代码风格尽量统一。我们需要用到以下工具:

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-case

ignore:
    - 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"
    ]
}
阅读 436

可视化数据开发工程师,自己独立开发了数据可视化网站[https://github.com/chuxiaoguo/mita],欢迎star

252 声望
18 粉丝
0 条评论
你知道吗?

可视化数据开发工程师,自己独立开发了数据可视化网站[https://github.com/chuxiaoguo/mita],欢迎star

252 声望
18 粉丝
宣传栏