npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

nodejs-dep-check

v1.2.61

Published

checks to see if all the dependencies in your code are reflected in package.json

Readme

nodejs-dep-check

installation

$ npm install --save-dev nodejs-dep-check

description

this module checks to see if all the dependencies in your code are reflected in package.json - you may have noticed that when you deploy code the build sometimes fails, or worse, after you deploy there's a runtime error because a require statement in your code references a dependency that didn't make into package.json for whatever reason.

therefore, ndc (nodejs-dep-check) should be incorporated in your continuous integration tests - this module is designed to be used as a static analysis test

you probably won't want this module for anything but testing, so you can use the --save-dev option instead of --save when installing with NPM

how to use

from the command line:

$ n-dc 

or

$ n-dc --conf path/to/ndc.conf.js --pkg.json path/to/package.json

use from anywhere in Node.js:

var ndc = require('nodejs-dep-check');

ndc.run({
    verbose:true,                             // prints more output, true is default, set this to false for less output at command line
    ignoreModules: ['colors/safe'],           // use this option to override the errors for a particular module, e.g. colors/safe is something this module doesn't currently handle
    ignorePaths: ['./node_modules','./scripts/someOldScript.js'],  // ignore specific paths, *not all* directories with this name, just the exact path you specify which is relative to the root of your node.js project
    ignoreDirs: ['node_modules','test']       // ignore all contents and subcontents in *any* dir called "node_modules" or "test" or whatever
});

note: you can ignore specific files by using either the ignoreDirs or ignorePaths options, just use '.js' with the filename

usage with Mocha


 describe('@test-dep-check', function () {

 
     it('[test]', function (done) {
 
         var ndc = require('nodejs-dep-check');
 
         var result = ndc.run({
             verbose: true,
             ignorePaths: ['./node_modules'],       //in this case, this is redundant, because having node_modules in ignoreDirs has us covered
             ignoreDirs: ['node_modules', 'test'],
             ignoreModules: ['colors/safe']
         });
         
         done(result);   // Mocha will handle the test case for you, because nodejs-dep-check.run() returns an instance of Error if any check fails
 
     });
 
 });
 

It's probably best used with a testing framework like Mocha, but you can also use it from the command line.

Caveats:

(1) Make sure the CWD is the root of your project (aka, you issue the node or mocha command where your package.json file is) (2) This module unfortunately cannot help you with dynamically resolved require calls (aka, require(path.resolve('foo' + '/bar')))

This module is configured by default to look at your entire project, so it always starts recursively with the root of your app.

here's typical output - you might notice that there is a line commented out

//var redis = require('redis');

this library doesn't ignore commented out lines - so you may wish to alter the comment into this:

//var redis = require#('redis'); (or whatever non-alpha-numeric character suits your fancy)

alt tag

any questions you can open an issue on Github or email me at [email protected], thanks