You’ll need to tell npm what type of release this is by specifying a valid semantic versioning type, such as major, minor, or patch.

It will also create a version commit and a new Git tag. This will automatically update the version number in package.json and package-lock.json. The easiest way to update your version number is to use the handy npm version command.

Recommendations for Project Maintainers.

Determining How to Release an Existing Project.

In this article, I’ll cover the most common release steps, how to determine the release process for an existing project, and recommendations for project maintainers. I wanted get a better handle on what’s typically involved in the npm release process. So I recently spent some time reading the npm docs and familiarizing myself with some of the most common release helper tools. Releasing a new version of any package was a little harder than it needed to be, since I had to figure out what process to use for each. None of this is bad, and I’m not trying to shame any other devs, but it did increase friction. Some used a release helper tool like npmpub, others had prepublish scripts, and others had nothing special at all. Because standards and best practices evolve quickly, each project’s release process was configured differently. Part of the problem was that these projects were created over many years, with multiple developers involved. However, as someone relatively new to the Operations side of things, I found myself getting lost about how exactly to release a new version of a package. Recently, I’ve been trying to do a bit more open source work, especially in the form of maintaining Cloud Four’s npm packages.

Package npm