Implementation of version management and automatic release of NPM package based on tag

summary

Automatic NPM package publishing has the following advantages:

1. Automatic operation, saving manpower
2. You can use docker and other environments to prepare a clean environment for each release to avoid missubmitting documents
3. Unified account can be used to simplify permission control
4. Direct contracting can be controlled on the web side without relying on the command line
5. It can realize the accurate control of NPM package version

So how to realize the automatic release of NPM package?

The answer is CI / CD.

Configuration in GitHub

There are many free CI / CD services available in GitHub. For example, Travis Ci, circle Ci, etc., I use Travis CI.

Install Travis Ci

Travis CI provides free CI / CD services for open source projects in GitHub, which can be accessed through GitHubmarketplacePage to install it.

Authorization of existing projects may be involved in the installation process. The operation is relatively simple. Travis also has corresponding documents, which will not be omitted here.

Configuring Travis CIS

Travis CI use travis. YML file. For specific configuration rules, refer to itsOfficial documents。

Let’s look at the next sample file first

language: node_js
node_js:
  - '8'
script: npm run lint && npm test
before_deploy: npm run build
deploy:
  provider: npm
  email: [email protected]
  skip_cleanup: true
  api_key:
    secure: your secret token
  on:
    tags: true
    branch: master
  tag: latest

In this sample file,language: node_jsIndicates the environment in which nodejs is to be used,node_js: 8Indicates the version using node 8

The combination of these two variables determines the docker environment that Travis will adopt in the CI process. You can also specify multiple node versions, which will be executed once in each version. Because we want to contract with it, we can only execute it once, so we only need to set an appropriate node version.

There are multiple execution phases in Travis,script: npm run lint && npm testIt refers to the script that Travis runs regularly. This step is generally used for testing. The operation I perform here is lint to check the code specification and test. The corresponding NPM script needs to be in package JSON is pre-defined, and the table is not skipped.

before_deployanddeployYou can explain its meaning by yourself, because I need to build it first when publishing my project, so I added itnpm run buildThe operation is before deploy.

It should be noted here that Travis will clean up by default before deploy. thereforebefore_deployFiles generated in cannot be directlydeployIf you want to keep these files, you need to set themskip_cleanupIs true.

api_keyIs an important field, which NPM uses for authentication. This data comes from the token management of NPM and is encrypted using the command line tool provided by Travis. For specific operations, please refer to the official Travis documentationhttps://docs.travis-ci.com/us…。

on:This option controls what conditions trigger deploy. I set the master branch or tags, or set only tags. That is, the build is triggered only when a new tag is created. In this way, whenever we create a new tag, the NPM package will be published automatically.

Automatically modify version and create tag

Please skip to the end of this article about NPM versioning.

Configuration in gitlab

Another commonly used git service is gitlab. Many companies choose to implement a private code warehouse based on gitlab.

Gitlab has its own CI / CD service. We can automatically publish NPM packages based on gitlab CI.

Configure gitlab Ci

Gitlab CI needs to configure runner before writing one gitlab-ci. YML configuration file.

Gitlab has documentation for this and does not omit the table. You can probably refer to the operations in GitHub.

Later, I will assume that there are already available runner and docker environments, and automatically publish NPM packages based on them.

stages:
  - publish

#Publish to NPM
publish:
  stage: publish
  only:
    - tags
  tags:
    - your-runner-tag
  script:
    - docker run --name npm-publisher --rm -v $(pwd):/home/node/code --workdir="/home/node/code" --env NPM_TOKEN=${NPM_TOKEN} node:8-alpine sh publish.sh

This file is relatively simpler. itsonly: tagsThis option specifies that publish can only be performed during tag operation

scriptThat is, the process of NPM release. Here I use the following method:

1. Docker run node: 8-alpine image to generate a new container
2. Mount the current directory (i.e. the directory where the code is located) to / home / node / code in the container, which can be written freely
3. Set workdir to the mount directory / home / node / code
4. NPM in the current environment_ The token variable is sent to the container as an environment variable
5. Finally, executesh publish.shScript, and publish in the script

publish. The SH script is as follows:

rm -rf /tmp/publisher \
&& mkdir -p /tmp/publisher \
&& cp -r . /tmp/publisher \
&& cd /tmp/publisher \
&& npm install \
&& npm run build \
&& npm test \
&& echo '//registry.npmjs.org/:_authToken=${NPM_TOKEN}' >> .npmrc \
&& npm publish

Here, the code is reproduced to / TMP / publisher before publishing, mainly to avoid the node generated in docker_ Modules affects the code directory on the host, causing some permission problems.

The publish operation isnpm install && npm run build && npm test && npm publish

The more important thing here is to create Npmrc file, write token and other information into the configuration file. We use environment variables such as ${npm_token}, which come from the parameters provided by the — env parameter in the docker run command. Where does ${npm_token} in the docker run command come from? This depends on the variable settings in gitlab CI.

Variable settings in gitlab Ci

You can set variables for CI in gitlab (Travis can also), but it is relatively special, so let’s talk about it separately.

In settings – > CI / CD of the project, there is the variables section, which can be used to set the environment variables used in CI.

Note that there is a protected option here. What is it used for? (opening it rashly may cause the variable to be unavailable)

The protected variable, in short, is only valid for the CI task corresponding to the protected branch or tag, which plays the role of password protection. Even if others modify it gitlab-ci. YML, the echo operation is added, and the password cannot be output.

To use the protected feature, you need to set the creation of tag to protected operation. You can set it in settings – > Repository – > protected tags, as shown in the following figure:

In this way, the defined NPM can be used normally in gitlab CI_ Token variable.

NPM version management

Generally speaking, we will use semver for version management.

That is, the versions of the three paragraphs are major minor. patch

The NPM tool provides the version command, which can be used to easily modify the package JSON, and automatically commit, and create the corresponding tag locally.

When there is a large version update or incompatible with the previous version, the major field should be upgradednpm version major

When a minor version is updated and new functions are added, the minor version can be upgradednpm version minor

When there are bug fixes and minor adjustments, upgrade the patch versionnpm version patch

When NPM versions are created at the same timeV version numberIn the form of tag, push the tag to automatically trigger the construction.

You can also simplify this operation and automatically push after NPM version operation

In package Add the following code to JSON to realize the NPM version operation. After the operation, automatically push the code and tag, and then automatically trigger the NPM release operation.

  "scripts": {
    "postversion": "git push --follow-tags"
  }

see

https://blog.npmjs.org/post/1…
https://docs.travis-ci.com/us…
https://docs.gitlab.com/ee/ci…
https://docs.gitlab.com/ee/ci…