likes
comments
collection
share

前端工作流

作者站长头像
站长
· 阅读数 21

背景

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

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

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

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

工作流概览

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

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