background
A Semantic Versioning number is a set of common rules for the evolution of software and its users, and a Semantic Versioning number is a set of common conventions for how a version number is specified. In our daily software production process, we not only produce software itself, but also some reusable code packages. These code packages are mashed together to produce a complete software and system, while the code packages continue to be developed to add new features or fix old problems. Under this trend, semantic version number rules can better refine software production and iteration, so that software assets can be updated and released in an orderly manner.
The version number consists of three digits: 1.0 [MAJOR].[MINOR].Copy the code
The three digits stand for different meanings:
- MAJOR the version when incompatible API changes are made
- The version of the feature that MINOR added in a backward compatible manner
- PATCH backward compatible bug fix version
For details, it is recommended to check Semantic Versioning convention in detail.
The problem
The team handed off some of the manual work to CI/CD tools, such as the release issues discussed in this article. At present, the software release process is based on manual modification of the version field in package.json file to achieve version update. After the front end starts modularizing the various common modules, there are a lot of code packages that need to be maintained. Human error can also be reduced by handing over some of the human tasks to machines to help front-line colleagues with some of the repetitive tasks.
The solution
The front-end’s current code package management tool, NPM, itself provides command tools to help coders solve the work of version upgrade. Here’s the code:
$ npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]
'npm [-v | --version]' to print npm version
'npm view <pkg> version' to view a package's published version
'npm ls' to inspect current package/dependency versions
Copy the code
The rules used are also designed to follow the semantic version number convention. Details of NPM official practices can be found at Sermver.inc.
Here is a description of the version options (assuming the default version is 0.2.0) :
options | describe | example | instructions |
---|---|---|---|
major | Major Updates | npm version major |
0.2.0 = “1.0.0 |
minor | Major Updates | npm version minor |
0.3.0 0.2.0 =” |
patch | Patch Update version | npm version patch |
0.2.1 0.2.0 =” |
premajor | Major updates pre-release versions | npm version premajor |
0.2.0 = “1.0.0-0 |
preminor | Major updates pre-release versions | npm version preminor |
0.2.0 = “0.3.0-0 |
prepatch | Patch Updates the pre-release version | npm version prepatch |
0.2.0 = “0.2.1-0 |
prerelease | Pre-release version | npm version prerelease |
An error occurs if the current version is not a pre-release version |
from-git | Take git’s tag as the version number and set it in package.json | npm version from-git |
Git throws an error if its tag is not set |
The use of prerelease is a prerequisite. The current version must be a pre-release version. If it is not a pre-release version, an error will be thrown. Providing additional parameters with [–preid] can also be used to detail the role of a pre-release version, such as the need to implement the following:
$NPM version premajor --preid beta v1.0.0-beta.0Copy the code
References to the content: docs.npmjs.com/cli/v7/comm…
Using the example
Scenario 1: Simple use
Current version: 0.2.0
Action: Update version to 0.2.1 and tag v0.2.1 in Git.
Update the new patch version # $NPM version patch # $git print git history log commit 39 c8ba50f0ef18aab41ac9c65669b2769ed3b3a7 (HEAD - > master, Tag: v0.2.1) Author: Packy <[email protected]> Date: Wed Apr 7 16:18:22 2021 +0800 0.2.1Copy the code
Scenario 2: Customize git commits
Current version: 0.2.0
Behavior: Update the version number and commit git, customize the commit description.
$NPM version major -m "version update to % s" v1.0.0 $git log commit 7 b9e3102111f8f86fc70d1b1fcab96bb9389df9b (HEAD - > master, the tag: V1.0.0) Author: Packy <[email protected]> Date: Wed Apr 7 17:01:36 2021 + 0800 version updates to 1.0.0 commit eda4316722a9d03f2fd5e60f61507a6e272ddc1b Author: Packy <[email protected]> Date: Wed Apr 7 11:01:202021 +0800 chore: Update packageCopy the code
Scenario 3: No Git operation
Current version: 0.2.0
Behavior: Only change the version field in the package.json file, no Git action is performed
# Update to the new patch version, Don't git tag $NPM version patch, no - git - tag - version $git log commit eda4316722a9d03f2fd5e60f61507a6e272ddc1b (HEAD - > master) Author: Packy <[email protected]> Date: Wed Apr 7 11:01:20 2021 +0800 chore: Update package $git status On branch master Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: package.json no changes added to commit (use "git add" and/or "git commit -a")Copy the code