1. Maintaining package dependencies with npm
The npm install command by itself, with no package name specified, installs the packages listed in the dependencies section of package.json. Likewise, the npm update command compares the installed packages against the dependencies and against what’s available in the npm repository and updates any package that is out of date in regards to the repository.
These two commands make it easy and convenient to set up a project, and to keep it up to date as dependencies are updated. The package author simply lists all the dependencies, and npm installs or updates the dependencies required for using the package. What happens is npm looks in package.json for the dependencies or devDependencies fields, and it works out what to do from there.
You can manage the dependencies manually by editing package.json. Or you can use npm to assist you with editing the dependencies. You can add a new dependency like so:
$ npm install akasharender –save
With the –save flag, npm will add a dependencies tag to package.json:
“dependencies”: {
“akasharender”: “^0.7.8”
}
With the added dependency, when your application is installed, npm will now install the package along with any other dependencies listed in package.json file.
The devDependencies lists modules used during development and testing. The field is initialized the same as the preceding one, but with the –save-dev flag. The devDependencies can be used to avoid some cases where one might instead perform a global package install.
By default, when npm install is run, modules listed in both dependencies and devDependencies are installed. Of course, the purpose of having two dependency lists is to control when each set of dependencies is installed.
$ npm install –production
This installs the “production” version, which means to install only the modules listed in dependencies and none of the devDependencies modules. For example, if we use a build tool like Babel in development, the tool should not be installed in production.
While we can manually maintain dependencies in package.json, npm can handle this for us.
1.1. Automatically updating package.json dependencies
With npm@5 (also known as npm version 5), one change was that it’s no longer required to add –save to the npm install command. Instead, npm by default acts as if you ran the command with –save, and will automatically add the dependency to package.json. This is meant to simplify using npm, and it is arguably more convenient that npm now does this. At the same time, it can be very surprising and inconvenient for npm to go ahead and modify package.json for you. The behavior can be disabled by using the –no-save flag, or it can be permanently disabled using the following:
$ npm config set save false
The npm config command supports a long list of settable options for tuning the behavior of npm. See npm help config for the documentation and npm help 7 config for the list of options.
Now let’s talk about the one big use for package dependencies: to fix or avoid bugs.
1.2. Fixing bugs by updating package dependencies
Bugs exist in every piece of software. An update to the Node.js platform may break an existing package, as might an upgrade to packages used by the application.
Your application may trigger a bug in a package it uses. In these and other cases, fixing the problem might be as simple as updating a package dependency to a later (or earlier) version.
First, identify whether the problem exists in the package or in your code. After determining it’s a problem in another package, investigate whether the package maintainers have already fixed the bug. Is the package hosted on GitHub or another service with a public issue queue? Look for an open issue on this problem. That investigation will tell you whether to update the package dependency to a later version. Sometimes, it will tell you to revert to an earlier version; for example, if the package maintainer introduced a bug that doesn’t exist in an earlier version.
Sometimes, you will find that the package maintainers are unprepared to issue a new release. In such a case, you can fork their repository and create a patched version of their package. In such a case, your package might use a Github URL referencing your patched package.
One approach to fixing this problem is pinning the package version number to one that’s known to work. You might know that version 6.1.2 was the last release against which your application functioned and that starting with version 6.2.0 your application breaks. Hence, in package.json:
“dependencies”: {
“module1”: “6.1.2”
}
This freezes your dependency on the specific version number. You’re free, then, to take your time updating your code to work against later releases of the module. Once your code is updated, or the upstream project is updated, change the dependency appropriately.
When listing dependencies in package.json, it’s tempting to be lazy, but that leads to trouble.
2. Explicitly specifying package dependency version numbers
As we’ve said several times in this chapter, explicitly declaring your dependencies is A Good Thing. We’ve already touched on this, but it’s worth reiterating and to see how npm makes this easy to accomplish.
The first step is ensuring that your application code is checked into a source code repository. You probably already know this, and even have the best of intentions to ensure that everything is checked in. With Node.js, each module should have its own repository rather than putting every single last piece of code in one repository.
Each module can then progress on its own timeline. A breakage in one module is easy to back out by changing the version dependency in package.json.
The next step is to explicitly declare all dependencies of every module. The goal is simplifying and automating the process of setting up every module. Ideally, on the Node.js platform, the module setup is as simple as running npm install.
Any additional required steps can be forgotten or executed incorrectly. An automated setup process eliminates several kinds of potential mistakes.
With the dependencies and devDependencies sections of package.json, we can explicitly declare not only the dependencies but the precise version numbers.
The lazy way of declaring dependencies is putting * in the version field. That uses the latest version in the npm repository. This will seem to work, until that one day the maintainers of that package introduce a bug. You’ll type npm update, and all of a sudden your code doesn’t work. You’ll head over to the GitHub site for the package, look in the issue queue, and possibly see that others have already reported the problem you’re seeing. Some of them will say that they’ve pinned on the previous release until this bug is fixed. What that means is their package.json file does not depend on * for the latest version, but on a specific version number before the bug was created.
Don’t do the lazy thing, do the smart thing.
The other aspect of explicitly declaring dependencies is to not implicitly depend on global packages. Earlier, we said that some people in the Node.js community caution against installing modules in the global directories. This might seem like an easy shortcut to sharing code between applications. Just install it globally, and you don’t have to install the code in each application.
But, doesn’t that make deployment harder? Will the new team member be instructed on all the special files to install here and there to make the application run? Will you remember to install that global module on all destination machines?
For Node.js, that means listing all the module dependencies in package.json, and then the installation instructions are simply npm install, followed perhaps by editing a configuration file.
While most packages in the npm repository are libraries with an API, some are tools we can run from the command line.
Source: Herron David (2020), Node.js Web Development: Server-side web development made easy with Node 14 using practical examples, Packt Publishing.