preface

Last time we talked about the engineering process of building component libraries and the methods associated with it. This time we are going to talk about standardization, including the versioning specification and the code development commit specification.

Version management

  • On Google forVersion controlVersion control is the standard practice of maintaining engineering blueprints, tracking them from birth to final decision. In addition, version control is a software engineering technique to ensure that the same program files edited by different people are synchronized throughout the software development process. For component libraries, version management is also particularly important to ensure the convenience of users and unified standardization of development.

The target

  1. The version number of the component library must meet the rules of semantic version 2.0.
  2. The Change Log of the corresponding version is automatically generated.

The solution

  • A Change Log depends on each commit, so once the commit information is normalized, the automation tool can extract the key update information from it and automatically generate the Change Log.

Commit the canonical

  • There are several specifications for writing commit messages. The most widely used is the Angular specification, which summarizes the commit type as follows:
Identification of instructions
feat New features
fix Bug fix
docs Document update
chore Other types that do not fall into the above categories, such as build processes, dependency management
style Code changes that do not affect program logic (whitespace characters, formatting indentation, filling in missing semicolons, etc., without changing code logic)
feat New features
refactor Refactoring code (no new features, no bug fixes)
test Add test cases or update existing tests
build The main purpose is to modify the commit of the project build system (e.g., configuration of glup, WebPack, Rollup, etc.)
ci The primary purpose is to modify the submission of the project continuing integration process (e.g. Travis, Jenkins, GitLab CI, Circle, etc.)
revert Roll back an earlier commit
  1. Install commitizen
1. yarn add commitizen --dev 2. commitizen init cz-conventional-changelog --yarn --dev --exact // The CBXM-Changelog is automatically installed and the corresponding Config items are generatedCopy the code
  1. increasescriptsThe script
"scripts": {
  "commit" : "git-cz"
}
Copy the code

After the YARN commit is executed, start CommItizen to verify the COMMIT information

> git cz

cz-cli@4.03., cz-conventional-changelog@3.02.

? Select the type of change that you're committing: (Use arrow keys) > feat: A new feature fix: A bug fix improvement: An improvement to a current feature docs: Documentation only changes style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) refactor: A code change that neither fixes a bug nor adds a feature perf: A code change that improves performance (Move up and down to reveal more choices)Copy the code
  1. One of the biggest problems with using Commitizen for commit validation is that not all developers choose to commit their code from the command line. If you use Git auto-commit management like VSCode, commit information cannot be intercepted and controlledcommitlint+huskyThe combination of the horse!

commitlint

  1. Install commitlint/cli
npm install --save-dev @commitlint/config-conventional @commitlint/cli
Copy the code
  1. increasescriptsThe script
"scripts": {
  "commitlint" : "npx commitlint -e $HUSKY_GIT_PARAMS"
}
// -e = -e; $= $
Copy the code
  1. Configure commitLint to commit specifications accordingly
  • Can be achieved bycommitlint.config.js..commitlintrc.js..commitlintrc.jsonOr,.commitlintrc.ymlFile and other methods can also be configured inpackage.jsonIn the configuration.
module.exports = {
  extends: ['@commitlint/config-conventional']}// @commitlint/ config-Conventional is a specification configuration plug-in based on Angular
Copy the code

husky

  • huskyGit inherits all hooks from git and prevents illegal hooks from being triggeredcommit,pushAnd so on. The current version is^ 6.0.0, the corresponding operation steps are as follows:
yarn add husky --dev
npx husky install
npx husky add .husky/pre-commit "npm run prettier"
Copy the code
  1. Install the Husky package;
  2. Open git hooks and create one in your project’s root directory.huskyFolder.
  3. Create the hook, followed by the script that will be executed during the hook firing phase.huskyGenerated in a folderpre-commitFile, the corresponding file under the step isnpm run prettierThe script is fired before the commit.

Note: The.huskyrc/.huskyrc.js file is not required

Automatically generate the Change log

  • Through open source toolsconventional-changelog-cliAutomatic log generation
  1. The installation
yarn add conventional-changelog-cli --dev
Copy the code
  1. increasescriptsThe script
"scripts": {
  "changelog": "npx conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
}
Copy the code
  1. The resulting CHANGELOG final style is as follows:
# 1.0. 0 (2019-11-06[a9ebf7e] [a9ebf7e](HTTPS://github.com/godbasin/wxapp-typescript-demo/commit/a9ebf7ee0ca53a4906ed77106b65f6d6bef92f9b))
Copy the code

Version standardization

  • throughstandard-versionAutomate version control.
  1. The installation
yarn add standard-version --dev
Copy the code
  1. increasescriptsThe script
"scripts": {
  "release": "npx standard-version --no-verify -t release-"
}
Copy the code

The release is done after all the version branches have been merged into the master to confirm that the release is correct.

conclusion

The versioning and development submission specifications are not only applicable to the component library project scenario, but also to our business project development, so the addition of these specifications will help improve the efficiency and quality of development. We will also update the component API design specifications and share the summary related to the automated release