乐趣区

关于vue.js:前端工作流

jiezi

背景

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

比方文件起名形式，有的人首字母大写，有的人首字母小写，在 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-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"
    ]
}
退出移动版