Before using a third-party package, you should get detailed information about it and, for example, consider the popularity, the license or known security issues. And once you’ve decided to use a package as dependency, you should continue keeping an eye on it. Check regularly that your dependencies are up to date, for instance, if there are bug fixes available and if no dependencies are missing or no longer being used.<\/p>\n
In this article, I will show you a couple of useful tools to properly address these issues and help you manage the dependencies of your Node.js applications.<\/p>\n
Before installing a package as a dependency of your project, use For example, to get the latest information about the “express” package, you would use the following command:<\/p>\n The information returned is formatted as JSON, which can be easily used for further processing, for example in the build process or when hooking into the preinstallation process before installing a package. While JSON is useful for that kind of automated processing, for manual checking I recommend using more specific subcommands of When installing a dependency using One of the tools that can help you avoiding both scenarios is “npm-check<\/a>“, which can be installed globally with the following command:<\/p>\n Let’s create a simple project to show the usage of “npm-check”: first install a dependency that is not used in the code and then use a dependency that is not referenced in the package.json file:<\/p>\n When you now run In April 2018 the former Node Security Platform<\/a>, also known as NSP, was bought by npm, Inc. and since npm@6 it\u2019s the base for checking security issues and vulnerabilities, which is activated by default when installing a package:<\/p>\n If you want to disable this behaviour, you can either pass the If you already have installed several packages and want to check for vulnerabilities for all of them, use If you want to automatically process this information, you can append the Node.js has a great community and a lot of packages that are continuously improved, be it improvements related to the performance, fixing of bugs or adding new features. Therefore one step of your build process should include checking for outdated dependencies. While you can manually check either the homepage of the package or the official registry, it’s easier to use the If you are looking for an alternative, check out “npm-check-updates<\/a>“, which comes with a different set of commands and options.<\/p>\n One of the basic best practices for Node.js development is to structure your code in many different, small, reusable packages, each having a special purpose. The extreme form of this are micro-packages<\/a>, often having only one exported function. But also without using this extreme form it can easily happen that you end up having dozens or even hundreds of packages for one project. This can get very complex if you manage every package in a separate Git repository, since you need to take care of the build process, the publishing and the deployment for each of those packages separately.<\/p>\n To overcome this problem, you might consider organising related packages in so-called mono repositories<\/strong>, or multi package repositories<\/strong>. The idea is quite simple: instead of having one Git repository for each package you just have one Git repository for a set of related packages. This way you can use the same scripts for organising the build, the publishing and the deployment for all of the packages. The most popular tool for managing multi package repositories is lerna.js<\/a>. Initially developed as part of Babel, it\u2019s now available as a separate tool and also used by other popular frameworks.<\/p>\n One of the most important things to check before using a package is its license. Does it fit the project that are you developing? Does it restrict the usage of the package? Is there a license at all? Or is it a custom license that you need to understand first?<\/p>\n A nice tool which gives you an overview of all the licenses in your dependency tree is “license-checker<\/a>“, which you can install globally using the following command:<\/p>\n If you keep the information in the JSON format for further processing, you can append the parameter If you are not sure whether a given license is suitable for you, have a look at choosealicense.com\/licenses\/<\/a>, which gives you a nice and understandable overview of several licenses and how they differ.<\/p>\n If you want to keep your packages or dependencies private, you have different options: you can use private Git repositories, use scoped packages at the official npm registry or you can use your own npm registry. The latter can be useful for different reasons, for example due to limited access to the internet, for caching packages or when using modified versions of a package.<\/p>\n One popular example for a private npm registry completely written in JavaScript is Verdaccio<\/a>, a Fork of the former sinopia<\/a>. It\u2019s available via npm and as a Docker image provided at Docker Hub<\/a>.<\/p>\n In this article I showed you some useful tools for managing your dependencies. But there is more. For example, if you are developing many different packages in parallel that depend on each other, it\u2019s useful to use Using third-party packages in your Node.js applications? This guide examines how to manage your Node.js depedancies to make sure they don’t cause you problems further down the line.<\/p>\n","protected":false},"author":2,"featured_media":19617,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,24],"tags":[],"class_list":{"0":"post-19609","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-guest-posts","8":"category-web-design"},"yoast_head":"\nnpm view<\/code> to get some details about the package: this includes the current version, the license that is used, information about the dependencies of the package, a short description, maintainers and much more.<\/p>\nbash\n$ npm view express<\/code><\/pre>\nnpm view<\/code> to get exactly the information that you are interested in:<\/p>\nbash\n# get the current version\n$ npm view express version\n4.16.3\n# get the license of that version\n$ npm view express license\nMIT\n# get a list of all versions available\n$ npm view express licenses\n[ '0.14.0',\n '0.14.1',\n '1.0.0-beta',\n '1.0.0-beta2',\n '1.0.0-rc',\n ...\n# get the required version of Node.js\n$ npm view express engines.node\n>= 0.10.0<\/code><\/pre>\nCheck for unused and missing dependencies<\/h3>\n
npm install<\/code>, the dependency is automatically saved in the configuration file (package.json) of the project. However, during the lifetime of a project it easily happens that a dependency is no longer needed, for example when it\u2019s removed from the code, but not removed from the configuration file. On the other hand it also happens that you simply forget to add a dependency to package.json but use it within your application code.<\/p>\nbash\n$ npm install -g npm-check<\/code><\/pre>\nbash\n$ mkdir example\n$ cd example\n$ npm init -y\n# install express but don't use it\n$ npm install express\n# use lodash but don't reference it\n$ echo \"const _ = require('lodash');\" > start.js<\/code><\/pre>\nnpm-check<\/code> within the root folder of that project, it gives you the following (shortened) output, which lets you easily track down both unused and missing dependencies:<\/p>\nbash\n$ npm-check\nexpress \ud83d\ude15 NOTUSED? Still using express?\n Depcheck did not find code similar to require('express') or import from 'express'.\n ...\nlodash \ud83d\ude1f MISSING! Not installed.\n \ud83d\ude1f PKG ERR! Not in the package.json. Found in: \/start.js<\/code><\/pre>\nFind vulnerabilities of dependencies<\/h3>\n
bash\n$ npm install express@4.5\n# ...\n+ express@4.5.1\nadded 33 packages from 22 contributors in 3.365s\n[!] 24 vulnerabilities found [54 packages audited]\n\tSeverity: 9 low | 9 moderate | 6 high\n\tRun `npm audit` for more detail<\/code><\/pre>\n--no-audit<\/code> parameter or disable it globally via npm set audit false<\/code>.<\/p>\nnpm audit<\/code>, which will do this recursively for your project. As a result, you get a list of known vulnerabilities including the following information:<\/p>\n\n
--json<\/code> to the command and it will give you a JSON report. Also note that if you are using an older version of npm where npm audit<\/code> is not available, you have a lot of great alternatives. Some of the most popular tools, for example, are Greenkeeper<\/a>, Snyk<\/a> and Retire.js<\/a>.<\/p>\nFind and fix outdated dependencies<\/h3>\n
npm outdated<\/code> command, which gives you a report including the following information: the name of the outdated package, the version that is used (e.g., 3.2.6), the latest version that can be installed according to the rules of semantic versioning (e.g., 3.21.2), and the latest version available (e.g., 4.16.3).<\/p>\nbash\n# install an older version of Express:\n$ npm install express@3.2\n$ npm outdated\nPackage Current Wanted Latest Location\nexpress 3.2.6 3.21.2 4.16.3 example<\/code><\/pre>\nManage internal dependencies<\/h3>\n
Check licenses for dependencies<\/h3>\n
bash\n$ npm install -g license-checker<\/code><\/pre>\n--json<\/code>. If you are just interested in an overview, use the parameter --summary<\/code> instead:<\/p>\nbash\n$ license-checker --summary\n\u251c\u2500 MIT*: 15\n\u251c\u2500 MIT: 3\n\u251c\u2500 UNKNOWN: 2\n\u251c\u2500 Custom: https:\/\/secure.travis-ci.org\/shtylman\/node-cookie.png: 1\n\u2514\u2500 ISC: 1<\/code><\/pre>\nKeep your dependencies private<\/h3>\n
There is more…<\/h3>\n
npm link<\/code> to create symbolic links, so that changes in one package immediately become visible in other packages. And last but not least: keep your own packages up to date, so that others can get the information they are looking for when they want to use them.<\/p>\n","protected":false},"excerpt":{"rendered":"