Checks if currently installed npm/bower dependencies are installed in the exact same versions that are specified in package.json/bower.json
To install the package and add it to your
npm install check-dependencies --save-dev
When dependencies are changed in
bower.json), whether it's a version bump or a new package, one can forget to invoke
npm install (or
bower install) and continue using the application, possibly encountering errors caused by obsolete package versions. To avoid it, use the
check-dependencies module at the top of the entry point of your application; it will inform about not up-to-date setup and optionally install the dependencies.
Another option would be to always invoke
npm install (or
bower install) at the top of the main file but it can be slow and
check-dependencies is fast.
Once the package has been installed, it may be used via:
All options from the API except
error can be passed to the CLI, example:
$ check-dependencies --verbose --package-manager bower --scope-list dependencies
Options accepting array values in the API (like
scopeList) should have each value passed individually, example:
$ check-dependencies --scope-list dependencies --scope-list devDependencies
callback is invoked upon completion and
config is a configuration object.
callback is invoked with the object containing fields:
status: number // 0 if successful, 1 otherwisedepsWereOk: boolean // true if dependencies were already satisfiedlog: array // array of logged messageserror: array // array of logged errors
The function returns a promise so passing a callback is not necessary; instead you can do:
The promise should never fail.
There is a synchronous alternative -- the following code:
var output = ;
will assign to
output the same object that would otherwise be passed to the
callback in the asynchronous scenario.
config object may have the following fields:
Package manager to check against. Possible values:
'bower'. (Note: for
bower you need to have the
bower package installed either globally or locally in the same project in which you use
Path to the directory containing
Default: the closest directory containing
bower.json (depending on
packageManager specified) when going up the tree, starting from the current one
Ensures all installed dependencies are specified in
NOTE: Don't use this option with npm 3.0.0 or newer as it deduplicates the file dependency tree by default so
check-dependencies will think many modules are excessive whereas in fact they will not.
Installs packages if they don't match. With the
onlySpecified option enabled prune excessive packages as well.
The list of keys in
bower.json where to look for package names & versions.
The list of keys in
bower.json where to look for optional package names & versions. An optional package is not required to be installed but if it's installed, it's supposed to match the specified version range.
This list is also consulted when using
By default, check-dependencies will skip version check for custom package names, but will still check to see if they are installed. For example:
If checkCustomPackageNames is enabled, check-dependencies will parse the version number (after the hash) for custom package names and check it against the version of the installed package of the same name.
By default, check-dependencies will skip version check for packages whose version contains the full repository path. For example:
If checkGitUrls is enabled, check-dependencies will parse the version number (after the path to the git repository and the hash) and check it against the version of the installed package.
Prints messages to the console.
A function logging debug messages (applies only if
A function logging error messages (applies only if
The most basic usage:
This will check packages' versions and report an error to
callback if packages' versions are mismatched.
install: trueverbose: truecallback;
will install mismatched ones and call
The following two examples:
behave in the same way -
callback is invoked upon completion; if there was an error, it's passed as a parameter to
This project aims to support all Node.js LTS versions in the "active" phase (see LTS README for more details) as well as the latest stable Node.js.
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using
Copyright (c) 2014 Michał Gołębiowski. Licensed under the MIT license.