“This is the second day of my participation in the November Gwen Challenge. See details of the event: The last Gwen Challenge 2021”.

Dear, hello, everyone. I am “Front-end Xiaoxin”. 😇 has been engaged in front-end development and Android development for a long time


Preface:

In the big front-end environment where Node is ubiquitous, it’s always a recurring process of creating or installing dependencies that rely on the NPM repository. Many friends have also released their own NPM packages, or upgraded them because some dependencies had problems, but you really knowpackage.jsonIs the version number in? Let’s learn together.

NPM Cli version:

The address of the website first attached document: docs.npmjs.com/cli/v7/comm…

The first command is:

npm version [<newversion>| major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>]| from-git] ​

  1. The operations for the command to specify the version number are as follows:NPM version 0.0.5;
  2. To publish the major version, run the following command:npm version major;
  3. To publish a minor version, run the following command:npm version minor;
  4. The command to release the patch version is as follows:npm version patch;
  5. The version that needs to be pre-released is plusprePrefix corresponding command;

​

We executed the command operation of specifying the version number and upgrading from patch to major version successively, please see the following figure:

Next, take a look at the execution of several pre-published commands, especially those specifying pre-published prefixes, as shown below:

​

Have you found a sense of the format of the version number above? Are you still manually modifying strings? By the way, have a look at yoursgitThe warehouse, you’ll findtagIt’s all typed up for you:

Sometimes you’re wondering, how easy is it for me to just use a numeric type when I’m comparing version numbers and doing an upgrade? I’m just going to do one decimal point and you’re going to have two?

Recommended here have some semantic version number is library semver * *, * * dependent libraries address is www.npmjs.com/package/sem… . This library provides common usage as follows:

const semver = require('semver')

semver.valid('1.23.') / / "1.2.3"
semver.valid('a.b.c') // null
semver.clean('  =v12.3.   ') / / "1.2.3"
semver.satisfies('1.23.', '1.x || >=2.5. 0 || 5.0. 0 - 7.23.') // true
semver.gt('1.23.', '9.87.') // false
semver.lt('1.23.', '9.87.') // true
semver.minVersion('>=1.0. 0') / / '1.0.0'
semver.valid(semver.coerce('v2')) / / '2.0.0'
semver.valid(semver.coerce('42.67.9.3.-alpha')) / / '42.6.7'
Copy the code

Next we’ll look at something about semantic version numbers:

  1. Version number composition: major version number. Revision number;
  2. Increment rules for version numbers:
    1. Incompatible API changes: main version +1;
    2. Backward compatibility: minor version +1;
    3. Backward compatibility bug fix: Revision number +1.
  3. Specification description:
    1. The project is in its infancy, everything can be overturned, and the major release number should be 0;
    2. When the project’s public API is ready for release, the version number should be 1.0.0 and subsequent updates should be based on this version;
    3. When we only make a problem fix for the current version, we should increase the revision number.
    4. When a new backward compatible feature is made or a public API is marked deprecated, the version number should be increased and the revision number returned to zero;
    5. When we add a public API with a change that is not backward compatible, we should increase the major version number and return the minor version number and revision number to zero.
    6. Sometimes versions are released ahead of time for use, and the pre-release version needs to be added, indicating that the version is not stable and may be incompatible.
  4. What happens when a feature is ready to die?
    1. Update files to make users aware of the change;
    2. Deprecate functionality in the appropriate next release;
    3. Officially deprecated and removed in the new major release, and keep deprecated features in a minor release to facilitate user migration;

For more details, XMD can read the documentation at semver.org/lang/zh-CN/

The summary is two points:

  1. When we do some modules for public use, please refer to the rules of semantic version number to execute, so that users can find the version they want;
  2. When we want to solve some problems through version upgrade, we can know which version can be used freely and which version should pay attention to compatibility.

Welcome to follow my public account “Front-end Xiaoxin students”, the first time to push original technical articles.