前端规范化工做流

时间  2021-02-17
标签 前端 node git github shell npm json gulp 性能优化 bash 栏目 Git 繁體版
原文   原文链接

代码规范校验，commit规范校验，CHANGELOG.md生成，版本升级，打tag，发布release前端

demonode

目前前端项目已经在pre-commit时使用lint-stage和eslint作了增量的代码格式校验，在代码层面作了必定程度的规范化。为了进一步规范前端开发的流程以及便于协同工做时方便其余人知道咱们每一个版本都作了些什么，或者咱们本身回顾本身作的东西时，更清晰易懂，没必要切到当时的分支去查看代码。所以，我对代码校验后的流程又作了以下的一些规范化优化：git

  1. 对commit使用Conventional Commits规范
  2. 在commit-msg阶段对commit进行校验
  3. 不管是项目仍是组件库都要有本身的版本，每完成一个版本都要采用semver规范，升级版本，而且打上tag
  4. 发版以后，根据提交的commit信息生成CHANGELOG.md
  5. 发布release,这里的release指的是github或者gitlab中的release

在开始前介绍整个流程前，先看下实现后的效果图: github

image
image

下面介绍在优化整个流程过程当中用到的工具(部分经常使用的工具只作简单介绍):shell

1. husky

拦截Git Hooks，让你在Git的生命周期作一些事情。这里使用的是 husky v4npm

huksy 支持全部Git Hooks:json

  1. 校验commit msg
  2. 校验代码格式
  3. 运行测试
    ...

2. lint-stage

使用huksy拦截Git Hooks，会致使，即使你只改了一个js文件，可是git commit的时候，仍是会校验全部的js文件gulp

lint-stage就能够解决上面发生的问题,它只会校验你提交或者说你修改的部份内容性能优化

3. eslint

代码格式校验bash

在开始介绍如何拦截commit-msg，并生成CHANGELOG.md以前，咱们须要先知道，目前比较主流的commit-msg规范是怎么样的？

conventional-commits是目前使用最广的写法，比较合理和系统化，而且有配套的工具

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 能够省略。

Header

Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）

（1） type用于说明 commit 的类别 
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变更）
refactor：重构（即不是新增功能，也不是修改bug的代码变更）
test：增长测试
chore：构建过程或辅助工具的变更
...
（2） scope用于说明 commit 影响的范围，好比数据层、控制层、视图层等等，视项目不一样而不一样。

（3）subject是 commit 目的的简短描述，不超过 50 个字符

Body

Body 部分是对本次 commit 的详细描述，能够分红多行

Footer

（1）不兼容变更

若是当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变更的描述、以及变更理由和迁移方法

（2）关闭 Issue

若是当前 commit 针对某个 issue，那么能够在 Footer 部分关闭这个 issue

Closes #123, #245, #992

4. commitizen交互式提交commit-msg

这里只介绍本地使用的方式，便于协同做业，安装的版本相同

# 安装
npm install --save-dev commitizen
# 安装适配器，使项目对commitizen友好
npx commitizen init cz-conventional-changelog --save-dev --save-exact

在package.json中配置

{
    "scripts": {
        "commit": "cz"
    }
}

// npm run commit 后将弹出交互命令行

若是想强制必须使用该交互方式，能够拦截prepare-commit-msg，那么在git commit时也会弹出交互命令行

{
    "husky": {
        "hooks": {
            "prepare-commit-msg": "exec < /dev/tty && git cz --hook || true"
        }
    }
}

5.commitlint

在介绍完conventional commit和交互式的commit工具以后，如今还须要一个能校验咱们所提交的代码是否严格遵循了conventional commit规范的工具。这个工具就是commitlint

这个工具使用很简单，仅需一下两步便可：

# Install commitlint cli and conventional config
npm install --save-dev @commitlint/{config-conventional,cli}

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

commitlint-config-conventional (based on the the Angular convention) 支持一下类型:

  1. build: 影响构建系统或外部依赖项的更改(示例范围:gulp、broccoli、npm)
  2. ci: 对 CI 配置文件和脚本的更改(示例范围:Travis, Circle, BrowserStack, SauceLabs)
  3. chore: 其余不修改 src 或测试文件的更改, 发版
  4. docs: 文档变动
  5. feat: 新的特性、功能
  6. fix: bug 修复
  7. perf: 性能优化
  8. refactor: 重构
  9. revert: 返回先前的提交
  10. style: 不影响代码含义的更改(空白、格式、缺乏分号等)
  11. test: 测试

6.conventional-changelog

commit-msg的交互式提交和格式校验工具都已经实现，下面就须要根据咱们的约定提交内容生成变动文档了CHANGELOG.md

conventional-changelog提取git log历史信息，而后生成文档

快速开始

$ npm install -g conventional-changelog-cli
$ cd my-project

# 在以前CHANGELOG.md基础上叠加，更新最近一个tag的commit msg
$ conventional-changelog -p angular -i CHANGELOG.md -s

# 更新所有commit msg，覆盖CHANGELOG.md
conventional-changelog -p angular -i CHANGELOG.md -s -r 0

在package.json中配置

{
    "scripts": {
        "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
    }
}

7. 自动发版工具standard-version

语义化版本控制版本格式：MAJOR.MINOR.PATCH，版本号递增规则以下：

主版本号：当你作了不兼容的 API 修改，
次版本号：当你作了向下兼容的功能性新增，
修订号：当你作了向下兼容的问题修正

standard-version是基于semver(Semantic Versioning)和Conventional Commits进行版本变动和生成 changeLog 的实用工具

standard-version做了如下几件事:

  1. 查看package.json中版本
  2. 升级package.json中版本号和package-lock.json中版本号
  3. 基于conventional-changelog 生成changelog
  4. 建立一个新的 commit（包含bumpFiles和更新的CHANGELOG）
  5. 基于新的版本建立tag

快速开始

  1. 安装依赖

npm install --save-dev standard-version

  1. 在package.json中添加脚本
{
    "scripts": {
        "release": "standard-version"
    }
}

// npm run release

8.conventional-github-releaser

发布到Github release或者GitLab release

使用前须要先设置环境变量CONVENTIONAL_GITHUB_RELEASER_TOKEN,github 获取Personal access tokens。若是是私有仓库选择 scope repo，若是是公开的仓库选择 scope public_repo

不建议将Personal access tokens放到项目本地使用，发布到github识别后会当即失效

快速开始

$ npm install -g conventional-github-releaser
$ cd my-project
$ conventional-github-releaser -p angular
// package.json
{
    "scripts": {
        "release": "conventional-github-releaser -p angular -n changelog-options.js -i CHANGELOG.md -s -r 0 -t e3c6d36e80b8faba29f44e91c5778a8271e83291"
    }
}

9.脚本配置

{
    "scripts": {
        "commit": "cz", // conventional-commit 交互式提交 commit
        "changelog": "conventional-changelog -p angular -n changelog-options.js -i CHANGELOG.md -s -r 0", // 生成 CHANGELOG.md
        "github-releaser": "conventional-github-releaser -p angular -n changelog-options.js -i CHANGELOG.md -s -r 0 -t e3c6d36e80b8faba29f44e91c5778a8271e83291", // 发布github或者gitlab releaser
        "update-project-version: project-minor": "node scripts/release/version-updater.js -t project -r minor", // 更新项目的版本信息
        "update-project-version: project-patch": "node scripts/release/version-updater.js -t project -r minor", // 更新项目的版本信息
        "update-package-version: patch": "node scripts/release/version-updater.js -r patch", // 更新组件库版本信息
        "update-package-version: minor": "node scripts/release/version-updater.js -r minor",// 更新组件库版本信息
        "tag": "node scripts/release/tag.js", // 打tag标签
        "release": "npm run tag && npm run github-releaser"
    }
}

10. 推荐工做流程

  • package(组件库)

    • 需求开发
    • 提交commit

    • beta发版

      • update-package-version: patch 更新组件库版本，而后打包publish

    • release发版

      • update-package-version: minor 更新组件库版本，而后打包publish
      • release分支从新发版，update-package-version: patch 更新组件库版本，而后打包publish

    • master发版

      • changelog -> 在CHANGELOG.md添加迭代相关信息 -> commit -> release

  • 迭代项目

    • 需求开发
    • 提交commit

    • beta发版

      • build

    • release发版

      • update-project-version: project-minor 版本，而后build
      • release分支从新发版，update-project-version: project-patch 更新版本，而后打包build

    • master发版

      • changelog -> 在CHANGELOG.md添加迭代相关信息 -> commit -> release
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程