Code specification verification, Commit specification verification, ChangeLog. md generation, version update, tag, release


Currently, the front-end project has done incremental code format validation at pre-commit using lint-stage and ESLint, and has done a degree of normalization at the code level. In order to further standardize the flow of front-end development and make it easier for people to see what we did with each release when we were working together, or for us to review what we did ourselves, so it’s easier to understand, so we don’t have to go to the branch and look at the code at the time. Therefore, I did the following normalized optimization for the process after code verification:

  1. rightcommituseConventional Commitsspecification
  2. incommit-msgStage ofcommitcheck
  3. Each project or component library should have its own version, which should be adopted as each version is completedsemverSpecifications, upgraded versions, and typedtag
  4. After the release, according to the submissioncommitInformation
  5. releasereleaseHere,releaseRefers to thegithuborgitlabIn therelease

Before introducing the whole process, let’s take a look at the renderings after implementation:

The following are the tools used to optimize the entire process (some commonly used tools are briefly introduced):

1. husky

Blocking Git Hooks allows you to do things within the Git lifecycle. Husky V4 is used here

Huksy supports all Git Hooks:

  1. checkcommit msg
  2. Verify code format
  3. Run tests…

2. lint-stage

If you use huksy to block Git Hooks, this will cause you to check all js files when you commit Git, even if you have changed only one

The lint-stage solves this problem by verifying only the parts of the content that you have submitted or that you have modified

3. eslint

Code format check

At the beginning of the introduction how to interceptcommit-msgAnd generateCHANGELOG.mdBefore we do, we need to know that the current mainstreamcommit-msgWhat is the specification?

Magmic-Commits are the most commonly used types of writing, which are reasonable and systematic, and have been described in particular by associative tools

For each Commit, the Commit message consists of three parts: Header, Body, and Footer.

< type > (< scope >) : < subject > / / short line < body > / / short line < footer >

The Header is required, and the Body and Footer can be omitted.


The Header section is a single line with three fields: Type (required), Scope (optional), and Subject (required)

typeThe category used to indicate the Commit

-Sheldon: A feature that fixes bugs, docs, and formats (changes that do not affect the running of the code). -Sheldon: Refactor (changes that are not new features, or changes to the code that fix bugs). Added test chore: Changes to the build process or assistive tools...

scopeThe scope of the COMMIT impact, such as the data layer, the control layer, the view layer, and so on, varies from project to project.

(3) Subject is a short description of the purpose of the Commit, not more than 50 characters


The Body section is a detailed description of the Commit, which can be divided into multiple lines


(1) Incompatible changes

If the current code is incompatible with the previous version, the Footer section begins with Breaking Change, followed by a description of the CHANGE, along with the reasons for the CHANGE and the migration method

(2) Close Issue

If the current commit is for an issue, you can close that issue in the Footer section

Closes #123, #245, #992

4. commitizenInteractive submissioncommit-msg

Here only introduces the local use of the way, easy to work together, the version of the same installation

# NPM install --save-dev commitizens # NPM install --save-dev commitizens Make the project Commitizens friendly NPX Commitizens Init CZ - MagXCom - Changelog -- Save-Dev -- Save-Exact

Configure it in package.json

{"scripts": {"commit": "cz"}} // NPM Run Commit pops up the interactive command line

If you want to force this interaction to be mandatory, you can intercept prepare-commit-msg, and the interactive command line will pop up at git commit

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


After introducing Conventional Commit and the interactive Commit tool, we now need a tool that verifies that our code is in strict compliance with the Conventional Commit specification. This tool is commitlint

This tool is very simple to use and requires only two steps:

# 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 Angular convention)

  1. build: Changes affecting the build system or external dependencies (sample scope :gulp, broccoli, NPM)
  2. ci: Changes to CI configuration files and scripts (sample range :Travis, Circle, BrowserStack, SauceLabs)
  3. chore: Any other changes that do not modify SRC or test files should be released
  4. docs: Document changes
  5. feat: New features and functions
  6. fix: bug fixes
  7. perf: Performance optimization
  8. refactor: refactoring
  9. revert: Returns the previous commit
  10. style: Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons, etc.)
  11. testTest:


Now that the interactive commit and format verification tools for COMMit-msg have been implemented, it’s time to generate a change document for the commit according to our convention

Conventional – ChangeLog extracts git log history information and generates a document

Quick start

$NPM install -g conventional-changelog-cli $CD my-project # install -g conventional-changelog-cli $CD my-project # install -g conventional-changelog-cli $CD my-project # install -g conventional-changelog-cli $CD my-project # MSG $commence-changeLog -p angular-i changeLog. Md-s # commit MSG $commence-changeLog -p angular-i changeLog. Md-s # commit MSG $changeLog -p angular-i changeLog. Overwrite ChangeLog. md Bexcom-ChangeLog-p angular-i ChangeLog. md-s-r 0 with ChangeLog. md Bexcom-ChangeLog-p angular-i ChangeLog. md-s-r 0

Configure it in package.json

    "scripts": {
        "changelog": "conventional-changelog -p angular -i -s -r 0"

7. Automatic publishing toolsstandard-version

Semantic version control version format: major.minor.patch, version number increment rules are as follows:

Major version number: when you make incompatible API changes, minor version number: when you make backward compatible functionality additions, revision number: when you make backward compatible problem fixes

Standard-version is a utility that makes version changes and generates changeLog based on Semver (Semantic Versioning) and Conventional Commits

Standard-version does the following things:

  1. To viewpackage.jsonIn the version
  2. upgradepackage.jsonChinese version number andpackage-lock.jsonThe version number
  3. Based on theconventional-changeloggeneratechangelog
  4. Create a new Commit (includebumpFilesAnd update theCHANGELOG)
  5. Created based on a new versiontag

Quick start

  1. Install dependencies

npm install --save-dev standard-version

  1. inpackage.jsonAdd a script to
    "scripts": {
        "release": "standard-version"

// npm run release


Post to the GitHub release or GitLab release

Need to set the environment variable CONVENTIONAL_GITHUB_RELEASER_TOKEN first before use, making access to the Personal access tokens. Select Scope repo for private repositories, or Scope public_repo for public repositories

It is not recommended to putPersonal access tokensUse locally in the project and publish togithubIt will be invalidated immediately after identification

Quick start

$ 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 -s -r 0 -t e3c6d36e80b8faba29f44e91c5778a8271e83291"

9. Script configuration

{"scripts": {"commit": "cz", // Beacon - Commit interactive commit" changelog": "conventional-changelog -p angular -n changelog-options.js -i -s -r 0", // create CHANGELOG. Md "github-releaser": "conventional-github-releaser -p angular -n changelog-options.js -i -s -r 0 -t E3c6d36e80b8faba29f44e91c5778a8271e83291, "released / / lot or gitlab releaser" update project - version: project - the 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",// update the library version information "tag": "Node scripts/release/tag.js", // "release":" NPM run tag &&npm run github-releaser"}}

10. Recommend workflow

  • Package (component library)

    • The requirements development
    • Submit the commit
    • Beta release

      • update-package-version: patchUpdate the component library version, then package itpublish
    • Release release

      • update-package-version: minorUpdate the component library version, then package itpublish
      • releaseBranch reissue,update-package-version: patchUpdate the component library version, then package itpublish
    • Master release

      • changelog– > inCHANGELOG.mdAdd iteration related information ->commit -> release
  • An iterative project

    • The requirements development
    • Submit the commit
    • Beta release

      • build
    • Release release

      • update-project-version: project-minorVersion, and thenbuild
      • releaseBranch reissue,update-project-version: project-patchUpdate the version, then package itbuild
    • Master release

      • changelog– > inCHANGELOG.mdAdd iteration related information ->commit -> release