1. Semantic version

1.1 Version number composition

Development requires the installation of various NPM packages, known as X.Y.Z, which follow the following semantic rules:

  • major

    Which of the abovex, represents the major version (API incompatible version, with major changes)

    Note: Large versions are not backward compatible
  • minorWhich of the abovey, represents the next version (such as adding a feature, backward compatibility)
  • patch

    Which of the abovez, represents patch versions (such as fixes for minor issues, backward compatible minor changes)

1.2 Upgrade version and label it

1.2.1 NPM Version Upgrade Commands

You can run the following command to automatically upgrade the version number based on the version semantic rules

# Upgrade patch version
npm version patch

# Upgrade version number
npm version minor

Upgrade the major version number
npm version major
Copy the code

1.2.2 Upgrade Process and Functions

Executing the upgrade script above will do the following for you:

  • Changing the Version number

Find package.json and package-lock.json and increase the version number accordingly according to the semantic rules

  • Commit this change

Git Add and Git commit are executed, and the commit log message (comment) is the version number

  • Label this upgrade

Git tag is executed

Note: This time the commit and marking of the modified version number are not pushed to remote

In this way, every update to Git is a separate commit (automatically changing the version number), which distinguishes git from other feature development and bug fixes.

1.2.3 Can be issued with the specified tag

If it is a front-end development project and Jenkins release, it can be refined by specifying a tag. Add a Parameter Type Tag and Build with Parameters. Of course, if you remember to push the tag to the remote, for example:

Git push Origin v0.1.0Copy the code

1. The script example

Here is a simple example of compiling and packaging an NPM package and then publishing it with an upgrade, in package.json:

  "scripts": {
    "serve": "vue-cli-service serve"."build:lib": "vue-cli-service build --target lib --name my-lib-name ./src/main.prod.js"."publish:patch": "npm run build:lib && npm version patch && npm publish"."publish:minor": "npm run build:lib && npm version minor && npm publish"."publish:major": "npm run build:lib && npm version major && npm publish"."lint": "vue-cli-service lint"
  },
Copy the code

Execute different commands depending on whether you want to upgrade to a major, major, or minor version:

# When the patch version needs to be upgraded
npm run publish:patch

# When an upgrade is required
npm run publish:minor

# When the main version needs to be upgraded
npm run publish:major
Copy the code

Before this, the corresponding branch may have been pulled before the development of the version. Here only the version number and tag are mentioned, and branch management is not involved. It can also be integrated into the compilation package and then synchronized to the demo example, which is not the focus of this article, omitted.

1.2.5 supplement

How do I manually modify the tag when it needs to be modified

  • Delete the localtag
   git tag -d tag-name
Copy the code
  • Delete the remotetag
   git push origin :refs/tags/tag-name
Copy the code
  • Modify and commit the code
  • Manual marking of the current versiontag
Git tag v2.0.1 -m "comment"Copy the code
  • Push the label to remote
Git push origin tag-name git push origin tagCopy the code

It is usually not recommended to send version and then modify! If problems are found after the release of the version, it is necessary to modify and release the new version. Relevant instructions are made on the version with problems, telling users to pay attention to the problems in this version and recommending upgrading to the new version.

2. NPM rules

2.1 About Default Rules

NPM install some-package-s Install some-package-s. By default, package.json dependencies will look like this:

"some-library-package": ^ "1.2.3"
Copy the code

The ^ before the version number indicates that updates other than the main version are allowed to be installed, such as:

The latest version Can you install
1. OK
1.3.0 OK
2.0.0 NG

2.2 About Locked Versions

According to the rules mentioned in 2.1 above, there is a problem that different people on the team pull the code, NPM install after, the installed version is not consistent, the environment is not consistent, can not guarantee that the code can run normally on everyone’s machine.

2.2.1 YARN

NPM is an official package manager installed with NodeJS. Due to some problems existing in NPM, large manufacturers are capable of making wheels and cars. Therefore, they try to improve their own, and yarn is created.

Yarn is a javascript package manager contributed by Facebook. It has been widely praised and used for its stability, reliability and speed (concurrent installation).

One of its features is that the yarn.lock file can be generated to lock the version of the dependency package, and the rest of the team can install the same version from the lock file after pulling the code.

2.2.2 Improvement of NPM

NPM also received feedback on the problem and saw the characteristics of YARN. Therefore, package-lock.json was created after 5.x.x, and the same version was installed for different members based on this. However, the lock file has a higher priority than package.json, which is not as sweet as expected:

  • When you want to upgrade a dependency package

    To modify thepackage.jsonThe installation is fixed according to the lock file
  • When adding dependency packages

    package.jsonAdd a dependency to lock file, but because lock file does not exist, so cannot install

This was not what one would expect with package-lock.json and was fixed after 5.1.0. Priority:

package.json > package-lock.json
Copy the code

2.2.3 Whether to Use Lock for NPM/YARN

Personally, I have always used NPM instead of YARN, not because I think YARN is bad, but because there are domestic image sources, NPM is enough, and the company has internal package manager, NPM can also absorb some excellent features of YARN. It itself is constantly evolving and getting better. (Such as lock files, such as workspace)

Personal advice is not to use lock files. Some people in the team use NPM and some use YARN. Sometimes package-lock.json conflicts with yarn.lock.

In addition, using the lock file to lock the version requires manual changes to the version number of package.json of the dependent company component packages, whether or not they change frequently, resulting in cumbersome and unnecessary coupling. (Preferably package-lock.json is also modified -> locally installed)

Personal practice

With all this in mind, here’s what I did when I personally developed the NPM package for business components in my company:

3.1 Configuring NPM Installation Rules

In 2.1 above, we mentioned the default rule, which can be changed:

npm config set save-prefix='~'
Copy the code

Or set it in the.npmrc configuration file as follows:

save-prefix = "~"
Copy the code

The latter is recommended so that the configuration does not have to be modified by each team member, but is written in the project.

The difference between ~ and the default ^ is that :(take js-cookie 1.8.2 as an example)

instructions case
^ 1.8.2 Upgrades other than major versions apply (minor and patch versions) 1.8.5 OK

1.9.1 OK

2.0.1 NG
~ 1.8.2 Only the patch version is applicable 1.8.5 OK

1.9.1 NG

2.0.1 NG
1.8.2 Fixed version 1.8.5 NG

1.9.1 NG

2.0.1 NG

If you install the specified version:

NPM install [email protected]Copy the code

When the fixed version is specified when the dependency package is first installed, the effect of locking the version is achieved without the lCOK file. It’s just not convenient to enjoy updates (such as bug-fixes).

3.2 Disabling the LOCK file

Personally, it is not recommended to use the lock file to lock the version, but to install the latest upgradable version based on semantics.

  • Avoid lock file conflicts
  • Avoid manually changing dependent version numbers
  • Avoiding older versions ensures that fixed problems are made available to users in a timely manner

If you don’t want to use lock files, you can manually delete them and add them to.gitignore. You can disable the lock file function directly:

npm config set package-lock false
Copy the code

Or set it in the.npmrc configuration file as follows:

package-lock = false
Copy the code

When disabled with the above configuration, the lock file is not generated at installation time, so you don’t need to delete it and add.gitignore.

The latter is recommended for the same reasons

To sum up, the configuration. NPMRC is:

save-prefix = "~"
package-lock = false
Copy the code

3.3 Summary Principles

The principle for upgrading dependencies in a project is,

  • Patch version, automatic upgrade
  • Second version adds features, manually ascending as needed
  • Major version API incompatible changes, manual upgrade on demand, generally not upgrade

Welcome to exchange comments

–END–