The purpose of this article is to provide a simple, straightforward tutorial for those who want to quickly build a set of industry-popular Angular team code submission specifications (not those for angular team code). The content of the article will not go into the details of each link, but will use popular words to let the partners who need to understand the meaning and role of each link, so as to build up the workflow of code submission from 0 to 1.

1. Format the COMMIT Message

I don’t want to emphasize the importance of the commit message here. We usually commit code with git commit -m “XXX” with a single sentence describing the code change, which is too easy to do for big or broken changes. Everyone has their own way of committing code, so we need a tool to generate a commit message that conforms to the specification and binds the commits.

Commitizen is a tool for formatting commit messages that constrain submitters to fill in commit messages step by step according to specified specifications.

Local installation

npm i -D commitizen

configuration

Write in package.json:

"script": {... ."commit": "git-cz",}Copy the code

This allows us to replace git commit with NPM run commit with commitizen’s git-cz.

2. Adopt the Angular team code submission specification

Now that we have Commitizen installed, a tool that generates specified Commit Messages, we need to create a set of filling specifications for Commitizen.

cz-conventional-changelog is a commitizen adapter for the angular preset of conventional-changelog A set of Angular team specifications for Commitizen. It’s widely used right now, so we’ll just quote it to Commitizen.

Local installation

npm i -D cz-conventional-changelog

configuration

Write in package.json:

"config": {
    "commitizen": {
        "path": "node_modules/cz-conventional-changelog"}}Copy the code

Once installed and configured, NPM run Commit will appear as follows:

3. Verify the COMMIT Message

Although the previous two steps have constrained a code submission specification, what if someone still doesn’t submit code according to the specification? Commitlint is required to validate commit messages and reject non-conforming Commit messages.

Like ESLint, commitLint requires a validation configuration. Don’t worry, there is a validation configuration @commitLint/Config-Conventional that goes with the CZ-Convention-Changelog specification (the Angular team specification) to help us verify commit message compliance.

Local installation

npm i -D @commitlint/config-conventional @commitlint/cli

configuration

After the installation is complete, create a configuration file commitlintrc.js or.commitlintrc.js in the root directory of the project and write: commitlintrc.js

module.exports = { 
    extends: [
        '@commitlint/config-conventional']}Copy the code

Or write in package.json:

"commitlint": {
    "extends": [
        "@commitlint/config-conventional"]},Copy the code

Commitlint can use the config-Conventional check configuration.

4. Set the verification time

By the third step, our code commit constraint specification is basically in place, and the last step is to configure when to trigger commit Message validation.

The best way to validate a Commit message is a combination of Git hook and husky.

What is a husky? It is simply a tool that lets you configure the behavior of each Git hook.

Local installation

npm install husky --save-dev

configuration

After the installation is complete, you also need to create the configuration file. Huskyrc or. Huskyrc.js in the project root directory and write:

{
    "husky": {
        "hooks": {... ."commit-msg": "commitlint -e $GIT_PARAMS"}}}Copy the code

Or write in package.json:

"husky": {
    "hooks": {... ."commit-msg": "commitlint -e $GIT_PARAMS"}}Copy the code

Git commitlint is a commitlint hook.

5. Automate code reviews

After the first three steps, we have built a workflow based on the Angular team’s code submission specification, but what if we want to validate the commit message as well as its specification?

Lint-staged projects allow you to perform a series of tests, fixes, formatting, etc., each time on a file from the staging area where you submitted (after Git added).

Local installation

npm install -D lint-staged

configuration

After the installation is complete, you also need to create a configuration file in the project root directory. Lintstagedrc and write:

{
  "*.{js,vue}": [
    "eslint --fix"."git add"]."*.{html,vue,css,sass,scss}": [
    "stylelint --fix"."git add"]}Copy the code

Or write in package.json:

"lint-staged": {
    "*.{js,vue}": [
    "eslint --fix"."git add"]."*.{html,vue,css,sass,scss}": [
    "stylelint --fix"."git add"]}Copy the code

Add the husky profile created in step 3:

"husky": {
    "hooks": {
        "pre-commit": "lint-staged"."commit-msg": "commitlint -e $GIT_PARAMS"}}Copy the code

Lint-staged configuration (lintStageDRC configuration means esLint checked and fixed the submitted JS or Vue file and resubmitted it into staging) in the pre-commit hook, Lint-Staged configuration is performed (lintStageDRC configuration means ESLint checked and fixed the submitted JS or Vue file and resubmitted it into staging).

6. Release

For each release of a new version of the project, we need to update the corresponding version number and document the changes. You can use the standard-Changelog tool to cooperate with NPM run version and automatically generate Changelog.

Local installation

npm install standard-changelog --save-dev
Copy the code

configuration

"scripts": {
   "version": "standard-changelog -f && git add CHANGELOG.md". }Copy the code

Executing the NPM run version command actually performs five actions:

  1. Modify thepackage.jsonVersion number in
  2. Modify thepackage-lock.jsonVersion number in
  3. generateCHANGELOG.mdfile
  4. submitpackage.json,package-lock.json,CHANGELOG.mdfile
  5. Enter this submission recordtag

It is a good practice to tag the release and record the changes when a project wants to release a new version.

The last

A complete workflow based on the Angular team’s code submission specification has been built, but you can also customize the specification if you don’t fit the Angular specification. Of course, some people may find it a hassle to write a commit, but a good commit convention can help your team develop more efficiently on a project, so use it in your own projects!