64

Inside a Node.js project, it's not clear to me what is the correct workflow to ugpgrade a package to a major release.

Let's suppose I'm istalling stylelint: npm install --save stylelint by default puts inside my package.json the string "stylelint": "^8.4.1" which means that if I want to update it with npm update, I will get only minor and patch releases (8.4.2 is ok, 8.5.0 in ok, 9.0.0 is not).

If I check with npm outdated and it comes out that I could update to 9.0.0, npm update wouldn't work because of the restriction depicted above.

So, if I want to upgrade, what am I supposed to do?

Have I to manually modify my package.json to stylelint version ^9.0.0, delete node_modules directory and re-run npm install?

Or maybe I have just to remove the ^ character to let npm update do its job?

What is the common/best practice to adopt?

Thanks

caneta
  • 1,612
  • 2
  • 20
  • 34
  • 23
    As you shared `npm update` only takes care of only minor and patch upgrade. However, for updating the major version **intentionally**, you could use `npm install` command without uninstall or manual removal. for your e.g. `npm install stylelint@9.0.0` or `npm install stylelint@latest` – Sourabh Mar 08 '19 at 05:24
  • Does this answer your question? [npm check and update package if needed](https://stackoverflow.com/questions/16525430/npm-check-and-update-package-if-needed) – Michael Freidgeim Jun 07 '20 at 08:26
  • Just run npm install with the new version tagged See my answer below. – Maciej Krawczyk Dec 06 '21 at 09:00

4 Answers4

38

Say you have "the-package" installed at version 3.x and want to upgrade to 5.x

You would do this:

npm install the-package@5

it will update package.json and package-lock.json as well.

You can also update multiple packages in one command like npm install package1@5 package2@16

To check which packages need updates, run npm outdated

Maciej Krawczyk
  • 14,825
  • 5
  • 55
  • 67
20

So, if I want to upgrade, what am I supposed to do?

In order to update major releases you can use the npm-check-updates.

See this great answer.

Shahar Shokrani
  • 7,598
  • 9
  • 48
  • 91
6

Or maybe I have just to remove the ^ character to let npm update do its job?

What is the common/best practice to adopt?

The most common/best practice is to never allow automatic updates to versions that have potentially breaking changes. Workflows are all over the map, from; manual test and then update packages.json, to fully automated detect, test, update and submission of packages.json.

Many Java/JavaScript environments are particularly sensitive to transitive dependency changes due to the lack of side by side versioning support. If your package brings in a breaking change of one of its own dependencies, then your package has introduced a breaking change to the system. If your 1.y.z causes an update of one of its dependencies from X.Y.Z to X+1.Y.Z it introduces a breaking change and is therefore not a stable version 1.y.z. Other packages that depend on the same package name as yours could potentially be broken whenever the developers of that package released a breaking change. Never let the world get into that state!

I recommend you study the Diamond Dependency Problem and take to heart. You should always carefully test breaking changes and never try to force them on your customers.

As pointed out by @ShaharShokrani, this answer gives a good workflow for manually updating your package. And to remain in compliance with SemVer 2.0.0 #8, don't forget to bump your own major version number.

jwdonahue
  • 6,199
  • 2
  • 21
  • 43
  • Ok, so no particular workflow defined exept for a lot of attention doing this kind of things! :-D Thank you for your answer and suggestion! – caneta Feb 22 '18 at 09:55
  • There are lots of DevOps products out there that provide all the mechanisms required for you to automate this scenario. Most of those tools canned scenarios are designed around the simplest workflows that don't involve much complexity on the dependency front, but most have all the hooks you need to create your own workflows. Generally speaking, you're going to write some scripts, it's how they lock you in. – jwdonahue Feb 22 '18 at 19:43
  • 32
    Don't know why this answer was accepted, as it doesn't actually answer the original user's question. – Geuis Aug 12 '18 at 21:21
  • @Geuis, the question was "What is the common/best practice to adopt?", and I answered accordingly, to the best of my knowledge. Have you got a better answer in mind? – jwdonahue Aug 13 '18 at 20:50
  • @Geuis, I have updated the answer. Maybe I should have simply voted to close this thread, since it's asking more than one question? If not for the `semantic-versioning` tag, I would never have seen this thread. I've always been more focused on the SemVer standard, than how any of the various packaging tools implement it. Had @ShaharShokrani answered this question earlier, I would have simply moved on. Back then, I really had zero interest in NPM and I did not want to leave a SemVer thread unanswered. – jwdonahue Jun 16 '21 at 18:18
3

You can also remove and install the package.

npm rm package
npm i package
Nick Redmark
  • 667
  • 6
  • 17