How to Export NPM Node dependency conflicts

Deadline is here, everything was working two days ago, but somehow your last commit is three days old. You have added a number of new libraries and discover a conflict in testing that had not appeared in the webpack-dev-server build.

You ask yourself why did you not commit more regularly. You wonder if anyone else might have introduced something that you pulled without testing. Of the 75 dependencies and devDependencies, several are new, and conflicts between them have led you to install one version after another of several without any success.

The refrigerator is empty, and everyone else has gone home.

Now that we understand the situation, let us find a way to shock everyone into the right-side of the morning when you get your three day old code back on the rails.

The Conundrum

We want stability, but we also know that we need to keep our code current to work with other current libraries. The problem is, that as we develop, the guarantees to work as expected are often associated with hard-coded versions of libraries that our applications require. Do you remember foolishly thinking that as long as you had "latest" in the package.json that your app would stay current? Whether or not you ever did, many of us have, and much of what we do as developers requires us to forever move our code forward while keeping a sharp eye out for conflicts.

Here are a few things to keep in your utility belt for dealing with node npm package.json dependency conflicts.

1. Regularly commit stable code

Relative to this topic, it is particularly important whenever adding new libraries to your package.json file. If you add a library, get in the habit of making a commit after testing it and ensuring that it did not add a problem to the app design or function.

2. There are a number of ways to check your package compatibility, such as depcheck, npm-check and npm-check-updates. I have found success or challenge with these as anecdotal. The former two used all my RAM with 100 packages to check and required a system reboot. I like npm-check-updates, which I have actually included in my build process to give information on package updates.

First install, then type ncu by itself.

npm install -g npm-check-updates

ncu


The list that is diplayed from typing 'ncu' into the command line gives the package.json version as well as the version number of the package to which it can be updated. Below is the text at the top and the bottom of the list of dependencies to be updated:

The following dependencies are satisfied by their declared version 
range, but the installed versions are behind. You can install the 
latest versions without modifying your package file by using npm 
update. If you want to update the dependencies in your package 
file anyway, run ncu -a.

[LIST OF FILES HERE]

Run ncu with -u to upgrade package.json

3. And saving the best for last, how do you determine which combination of packages are required when you know that one of them has to be a specific version? This is actually the motivator of this article: something provided by npm itself, which suggests that it may be the best way to solve this issue:

npm info "webpack@^1.13.2" dependencies

npm info "webpack-dev-server@1.16.2" devDependencies

npm info "eslint-config-airbnb@latest" peerDependencies

Each of the lines of code above will show you which versions of dependency packages are required.

npm info "superagent@3.1.0" devDependencies

{ Base64: '^1.0.0',
  'basic-auth-connect': '^1.0.0',
  'body-parser': '^1.15.0',
  browserify: '^13.0.0',
  'cookie-parser': '^1.4.1',
  express: '^4.13.4',
  'express-session': '^1.13.0',
  marked: '^0.3.5',
  mocha: '^3.1.2',
  multer: '^1.2.0',
  should: '^11.1.1',
  'should-http': '^0.0.4',
  zuul: '^3.11.1' }

Lastly, if you are not familiar with the different symbols that npm uses for versioning, look at the link below. Particularly, knowing when to use an exact version, or one that has a caret (^) or tilde (˜) can help keep your application as current as it needs to be, without making it more current than it can be.

I hope that this saves some people enough time to enjoy the rest of their day. There are few things more frustrating than sacrificing afterwork hours to fix things that should never have been allowed to break.

To view or add a comment, sign in

More articles by Kevin Ready

Explore content categories