Deprecating buggy npm packages, dealing with deprecations

; Date: Thu Aug 25 2016

Tags: Node.JS »»»» Node Web Development

It seems several critical npm packages deprecated older releases. Installing the old version of some packages causes npm to print a warning saying the package was deprecated, and to use a newer version of the package. Sometimes the message suggests a way to figure out where the package is being required. Due to the way an npm package can pull in other npm packages, it can be tricky to figure out where the deprecated package version is being used.

Example:

$ npm install hostr@2.3.2
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated lodash@2.4.2: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0
hostr@2.3.2 node_modules/hostr
├── colors@1.1.2
├── lodash@2.4.2
├── minimatch@2.0.10 (brace-expansion@1.1.6)
├── tiny-lr@0.1.7 (parseurl@1.3.1, livereload-js@2.2.2, qs@2.2.5, debug@2.0.0, faye-websocket@0.7.3, body-parser@1.8.4)
└── argr@1.1.7 (lodash@3.10.1)

Note this is fixed in the hostr package, but I wanted to demonstrate the problem.

Deprecating old versions of your package

One thing that's going on is that somehow the minimatch and lodash project maintainers got npm to print these messages. This is done with the npm deprecate command. The USAGE is:

npm deprecate <name>[@<version>] <message>

So to get these messages the respective authors ran these commands:

npm deprecate "minimatch@<3.0.2" "Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue"
npm deprecate 'lodash@<3.0.0' 'lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0'

Q.E.D.

What to do about deprecated dependencies

You could ignore the message. Your code is working, so what's the big deal? Uh... are you sure you're a software engineer and have that attitude? Clearly if the package maintainer went to the trouble of deprecating their package that indicates something should be changed.

The first stage is to determine whether the dependency is yours. Did your package directly make this stale dependency? Simply consult the dependencies section of your package.json to see. If so, update the version as directed.

Sometimes the dependency is indirect - that one of your dependencies depends on the stale package version. In such a case you have to contact the upstream package maintainer to get them to update their dependencies.

This can be determined with the npm ls command

$ npm ls lodash
/Users/david/bin
└─┬ hostr@2.3.2
  ├─┬ argr@1.1.7
  │ └── lodash@3.10.1
  └── lodash@2.4.2

In this case the argr package has a dependency on the up-to-date package, while the hostr package has the stale dependency.

In this case I contacted the hostr author, and he thanked me for noting the problems, and fixed them. This works with no warnings or errors:

$ npm install hostr@2.3.5

What if the upstream package author is not so responsive? "It Depends" is the only answer. Suppose it's an outright dangerous problem, and if the upstream author doesn't want to fix it then you might have to refactor your application to avoid this dependency. There are plenty of packages available and maybe another will serve your need just as well (or better).

About the Author(s)

(davidherron.com) David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.

Books by David Herron

(Sponsored)