In our daily work, when components are used across projects, we often choose to extract the components into npm packages. So is there anything to be aware of during the development and release of npm? From my own point of view, this article will introduce some of the points that I think need your attention.

From the daily development we can see that the version number of the npm package is in the format of X.Y.Z. So why do npm packages released by everyone follow this format? The format was actually created by Gravatars founder and GitHub co-founder Tom Preston-Werner A uniform version number representation rule drafted by GitHub called Semantic Versioning. You can refer to [Semantic Version 2.0.0] This article only describes some details on the areas that are easy to overlook in our development.

X stands for the major version number, also known as the major version number

Upgrading a major version means that the package may have made disruptive changes and is no longer compatible with the lower version of the package. Whenever the major version number is incremented, the minor version number and revision number must be zeroed.

Y represents the minor version number, also known as the minor version number

When the down-to-back compatibility feature is added, upgrade the minor version number. Whenever the minor version number is incremented, the revision number must be zeroed.

Z stands for revision number

When a bugfix is made for backward compatibility, the revision number is upgraded.

There are many more about the version format of npm and will not be repeated here.

As can be seen from the introduction to the common format above, in the case of the exact version number, the version number is completely fixed, and there will be no inconsistency between the version number of the actual installed package and package.json when the project is released. Or if the user uses the package-lock.json file to fix the version of the package, you can also avoid the problem caused by the version number of the package.

But in actual development, we don’t know if the users of our packages are using a fixed version number or a package-lock.json file, so what can we do to keep the users unaffected?

At this time, the prior version number will be used, and I will introduce it to you in detail below.

npm’s previous version number, placed after X.Y.Z, as an extension. A pre-release number indicates that the version is not stable and may not meet the expected compatibility requirements. For example: 1.0.0-alpha.1, 2.0.0-beta.1, etc. Commonly used keywords are:

We use npm dist-tag ls @zcy/zcy-region-detail-back to view the tag for @zcy/zcy-region-detail-back as follows:

We can see that this package has a beta version, a latest version.

Comparing the names of the two versions, it can be seen that the beta version adds 1 to the Z of the latest version and adds a beta as an extension.

If you need to bugfix on the extended version, we just need to continue to increase the extended version. When the bugfix is over and the official version needs to be released, just remove the extended version and release the version.

Suppose the P project references the @zcy/zcy-region-detail-back package as follows:

A requirement changes project P and is published at 6.30.

B Requirements changed the @zcy/zcy-region-detail-back package at 6.29.

B Requirements changes are not made using previous versions and bugs in the package were not modified when Project P was released in 6.30. This will cause the project P to be released, and the @zcy/zcy-region-detail-back package with a bug is downloaded, which will cause online problems.

This is because after we executed npm i @zcy/zcy-region-detail-back in the P project, the downloaded version number of @zcy/zcy-region-detail-back was 1.0.0. Because when npm i @zcy/zcy-region-detail-back is executed, the latest package under latest is downloaded by default. The equivalent of executing npm i @zcy/zcy-region-detail-back@latest. Note: tag here refers to tag in npm.

So what exactly is the use of npm’s tag? In fact, tag is equivalent to the tag in the branch management of git, and the packages between different tags do not affect each other. This allows us to release a previous version without affecting the official version.

There are three types of tags commonly used:

So how do we release a previous version of the package? You first need to upgrade the version number of package A, and two upgrade methods are described here

Method 1: Simple and rude, manually modify the version in package.json:

This way requires us to manually execute git commit -am ‘XXXX’ commit code, if we need to tag this version of the git repository, we need to manually trigger git tag v2.3.2-beta.1, git push origin v2.3.2-beta.1.

Method two: with the npm version command

After all changes in package A are committed, you can update the version according to the following command

According to the API above, we can see that we can upgrade the version of A to 2.3.2-beta.1 through npm version 2.3.2-beta.1, in addition, after npm 6.4.0, we can also use the –preid parameter to add a prefix:

It is important to note that the local modification must be committed before it can be executed. npm version modifies the version number, will default to git add -> git commit -> git tag operation, the version number at this time looks beta, as follows:

But this beta is the tag of the git repository, not the tag of npm. If you do not want to tag git by default, you can use the following command:

So what exactly happens when the npm version executes? A brief flowchart is shown below

After executing npm version 2.3.2-beta.1, if you directly use npm publish to publish, the tag of the published package is latest, but we actually want to release a test package. If someone else npm i downloads, the package with version 2.3.2-beta.1 will be downloaded. Only using npm publish –tag XXX tags npm packages.

Execute the following command to generate a package with a tag of beta:

If you accidentally send the wrong one directly with npm publish, you can use the following command to add a tag:

When you need to remove extra tags:

Provide you with a command to complete the beta release:

After the code is developed and committed, only npm run publish:beta can release a beta version~

The above is all the content I have shared this time, if there is any deficiency, I hope to correct it.

Semantic version 2.0.0 (

Front-end engineering (5): The npm knowledge you need is all here (

npm version (

If you find this article inspiring to you, I would like to invite you to help me with two small things

1. Click “Watching” so that more people can see this content (click “Watching”, bug -1 😊 )

ZooTeam, a young passionate and creative front-end team, is affiliated to the product research and development department of Zhengcaiyun, and the base is in picturesque Hangzhou. The team has more than 90 front-end partners, with an average age of 27 years old, nearly 30% of them are full-stack engineers, and the proper Youth Storm Regiment. The composition of members includes “veterans” from Ali and NetEase, as well as fresh graduates from Zhejiang University, China University of Science and Technology, Hangzhou Electric Power and other schools. In addition to daily business docking, the team also conducts technical exploration and practical combat in the direction of material system, engineering platform, construction platform, performance experience, cloud application, data analysis and visualization, etc., promotes and implements a series of internal technical products, and continues to explore the new boundaries of the front-end technology system.

If you want to change what has been tossed around, I hope to start tossing things; If you want to change the constant admonition you need to think more, but you can’t break the game; If you want to change what you have the ability to do and do that result, but you don’t need it; If you want to change what you want to do, you need a team to support, but there is no place for you to lead people; If you want to change the established rhythm, it will be “5 years working and 3 years work experience”; If you want to change the original understanding is good, but there is always that layer of window paper blurring… If you believe in the power of belief, believe that ordinary people can achieve extraordinary things, and believe that you can meet a better version of yourself. If you want to participate in the process of taking off as your business takes off, personally promoting the growth of a front-end team with in-depth business understanding, perfect technical system, technology creates value, and influence spillover, I think we should talk. Any time, wait for you to write something, send it to