npm: Semantic Versioning using npm

Join the AI Workshop to learn more about AI and how it can be applied to web development. Next cohort February 1st, 2026

The AI-first Web Development BOOTCAMP cohort starts February 24th, 2026. 10 weeks of intensive training and hands-on projects.


If there’s one great thing in Node.js packages, is that all agreed on using Semantic Versioning for their version numbering.

The Semantic Versioning concept is simple: all versions have 3 digits: x.y.z.

  • the first digit is the major version
  • the second digit is the minor version
  • the third digit is the patch version

When you make a new release, you don’t just up a number as you please, but you have rules:

  • you up the major version when you make incompatible API changes
  • you up the minor version when you add functionality in a backward-compatible manner
  • you up the patch version when you make backward-compatible bug fixes

The convention is adopted all across programming languages, and it is very important that every npm package adheres to it, because the whole system depends on that.

Why is that so important?

Because npm set some rules we can use in the package.json file to choose which versions it can update our packages to, when we run npm update.

The rules use those symbols:

  • ^
  • ~
  • >
  • >=
  • <
  • <=
  • =
  • -
  • ||

Let’s see those rules in detail:

  • ^: if you write ^0.13.0 when running npm update it can update to patch and minor releases: 0.13.1, 0.14.0 and so on.
  • ~: if you write ~0.13.0, when running npm update it can update to patch releases: 0.13.1 is ok, but 0.14.0 is not.
  • >: you accept any version higher than the one you specify
  • >=: you accept any version equal to or higher than the one you specify
  • <=: you accept any version equal or lower to the one you specify
  • <: you accept any version lower to the one you specify
  • =: you accept that exact version
  • -: you accept a range of versions. Example: 2.1.0 - 2.6.2
  • ||: you combine sets. Example: < 2.1 || > 2.6

You can combine some of those notations, for example use 1.0.0 || >=1.1.0 <1.2.0 to either use 1.0.0 or one release from 1.1.0 up, but lower than 1.2.0.

There are other rules, too:

  • no symbol: you accept only that specific version you specify (1.2.1)
  • latest: you want to use the latest version available

Lessons in this unit:

0: Introduction
1: How to use or execute a package installed using npm
2: npm dependencies and devDependencies
3: How to fix the "Missing write access" error when using npm
4: npm can install packages in the parent folder
5: Install an older version of an npm package
6: Find the installed version of an npm package
7: How to test an npm package locally
8: npm global or local packages
9: What are peer dependencies in a Node module?
10: `npm run dev` is a long-running program
11: ▶︎ Semantic Versioning using npm
12: Uninstalling npm packages with `npm uninstall`
13: An introduction to the npm package manager
14: The npx Node Package Runner
15: The package.json guide
16: The package-lock.json file
17: What is pnpm?
18: Should you commit the node_modules folder to Git?
19: Update all the Node dependencies to their latest version
20: Where does npm install the packages?
21: Bumping Node.js dependencies
22: Run package.json scripts upon any file changes in a folder