前端規範化工做流

時間 2021-02-17

標籤前端 node git github shell npm json gulp 性能優化 bash 欄目 Git 简体版

原文原文鏈接

代碼規範校驗，commit規範校驗，CHANGELOG.md生成，版本升級，打tag，發佈release前端

目前前端項目已經在pre-commit時使用lint-stage和eslint作了增量的代碼格式校驗，在代碼層面作了必定程度的規範化。爲了進一步規範前端開發的流程以及便於協同工做時方便其餘人知道咱們每一個版本都作了些什麼，或者咱們本身回顧本身作的東西時，更清晰易懂，沒必要切到當時的分支去查看代碼。所以，我對代碼校驗後的流程又作了以下的一些規範化優化：git

對commit使用Conventional Commits規範
在commit-msg階段對commit進行校驗
不管是項目仍是組件庫都要有本身的版本，每完成一個版本都要採用semver規範，升級版本，而且打上tag
發版以後，根據提交的commit信息生成CHANGELOG.md
發佈release,這裏的release指的是github或者gitlab中的release

在開始前介紹整個流程前，先看下實現後的效果圖: github

下面介紹在優化整個流程過程當中用到的工具(部分經常使用的工具只作簡單介紹):shell

1. husky

攔截Git Hooks，讓你在Git的生命週期作一些事情。這裏使用的是 husky v4npm

huksy 支持全部Git Hooks:json

校驗commit msg
校驗代碼格式
運行測試
...

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) 支持一下類型:

build: 影響構建系統或外部依賴項的更改(示例範圍:gulp、broccoli、npm)
ci: 對 CI 配置文件和腳本的更改(示例範圍:Travis, Circle, BrowserStack, SauceLabs)
chore: 其餘不修改 src 或測試文件的更改, 發版
docs: 文檔變動
feat: 新的特性、功能
fix: bug 修復
perf: 性能優化
refactor: 重構
revert: 返回先前的提交
style: 不影響代碼含義的更改(空白、格式、缺乏分號等)
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做了如下幾件事:

查看package.json中版本
升級package.json中版本號和package-lock.json中版本號
基於conventional-changelog 生成changelog
建立一個新的 commit（包含bumpFiles和更新的CHANGELOG）
基於新的版本建立tag

快速開始

安裝依賴

npm install --save-dev standard-version

在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