I've recently started developing a project in Node.js. Of course, right now the packages I'm using are pretty up-to-date as I'm starting afresh and using the latest version, but there's a pretty high version turnover rate for most Node.js packages and often certain features will be deprecated or dropped, and of course security vulnerabilities will be fixed.

Since most of my packages are specified using the semantic versioning syntax ^1.2.3 (stick to the given major version number to avoid breaking changes), any important updates beyond the current major version will be lost.

What is a prudent way to ensure that you stay reasonably up-to-date with your dependencies? Is it necessary to put, say, a weekly check for updates to your dependencies into your workflow to make sure you don't fall way behind? And for this reason, would it be a good idea to try and minimize dependencies to minimize the pain of dealing with breaking changes when you necessarily update to newer major versions?

  • 1. Become aware of a package update, 2. Evaluate the changes made in the update, 3. Decide if the changes are useful and relevant to your project. If they are, then 4. Upgrade the package to the new version. Sep 21, 2016 at 22:02
  • @Robert Harvey. My simple node project uses about a dozen major packages directly, with possibly a hundred indirectly. Your approach doesn't scale. This is a good question to check if there is an easier, more automated way.
    – user949300
    Sep 22, 2016 at 4:45
  • 1
    @Jez, have you looked at npm-check-updates or the npm outdated command? Never used either myself but they look like a start.
    – user949300
    Sep 22, 2016 at 4:53
  • If you're using GitHub, you may want to try something like Greenkeeper which will run your tests against new versions of your dependencies.
    – Whymarrh
    Oct 10, 2016 at 22:37

2 Answers 2


This is the workflow that I currently use for a project with monthly releases.

  • After release, go through the dependencies and update those that have only minor changes and patch updates. Since npm follows semantic versioning, if the authors of the packages did their job fine, this should not break your system.
  • Perform a smoke test and if any dependency is broken, create a task for development to update that dependency. It could be a ticket, it could be a task for your sprint, etc. The point is that updating those not immediate and will require work, so you have to schedule it. Any feedback from your first try will help.
  • Schedule tasks to update dependencies that have major changes.
  • Freeze your dependencies to the newest versions.

The objective is not to have automated updates at all. They might break your system in a way that you don't expect and very likely when you were making other changes, which will not help in figure out what the problem is.

Updating dependencies should be a conscious process, and if any of them break your system, you should be aware of which one.

Minor updates that break and go unnoticed will likely be picked up in your sprint of development or testing, and this is why you do it after release, because you want as much time to detect it and react to that issue before going live.

Note that I actually use this process on a .NET + Nuget dependencies project, but it pretty much applies to Node and npm / bower, Rails + bundle etc.

Finally, you can make use of nice commands that will help you in freezing/unfreezing dependencies, even adding them to your repo. See npm shrinkwrap.


I use another solution with a different approach https://uptodatenpm.com it sends you a weekly newsletter with information of new versions of your project’s dependencies so that you can decide which deps to update.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.