It's suprising how many libraries are in the average dependency tree that don't belong there for one reason or another. Either because they were accidentally listed as `dependencies` instead of `devDepedencies`, or they are required in a file as variables, but the variable is never actually used (poor linting), and so on. Or because the maintainer made the decision to add the deps, even though they will never ([or can't ever](https://github.com/felixge/node-dateformat/issues/36)) be used by 99.9% of users.
Worse, many libraries like chalk and [shelljs](https://github.com/eslint/eslint/issues/7316) actually execute code when `require()` is called!? (shelljs was modifying the `String.prototype`, and chalk loops over some objects to dynamically create methods). In other words, they do something like this:
```js
// in the main export of a library, if you do this it will
// automatically modify the String.prototype _globally_,
// the moment node.js loads the dependency tree
String.prototype.foo = function() {};
// same if you do something like this
// (dont' do this, ever. wrap this kind of code in a function
// and allow implementors to decide when to call it)
while (foo) {
// do stuff
}
```
In any case, just having these libraries in your dependency tree somewhere means that their code will excecute the moment you run your application _even if the libraries are never called by your application or any other code anywhere in the tree_.
**solution**
lazy-cache doesn't use any "magic", it uses native, plain-vanilla, tried and true javascript getters to call node's `require()` system.
**Faster, safer code**
There main advantage to this, the main is that `require`s are loaded on demand, so only code that is actually used will ever be loaded. As a result, applications will load faster (sometimes much faster - we've seen load times drop from ~1 second to less than 50 milliseconds).
Moreover, in some cases this also avoids inadvertently loading libraries that execute code or modifies globals, etc.
**webpack users**
If you use webpack and are experiencing issues with lazy-cache, this is a known bug caused by webpack, not lazy-cache. There is a solution though, you can use [unlazy-loader](https://github.com/doowb/unlazy-loader), a webpack loader that _fixes the webpack bug_.
[lint-deps](https://www.npmjs.com/package/lint-deps): CLI tool that tells you when dependencies are missing from package.json and offers you a… [more](https://github.com/jonschlinkert/lint-deps) | [homepage](https://github.com/jonschlinkert/lint-deps "CLI tool that tells you when dependencies are missing from package.json and offers you a choice to install them. Also tells you when dependencies are listed in package.json but are not being used anywhere in your project. Node.js command line tool and API")
_(This document was generated by [verb-generate-readme](https://github.com/verbose/verb-generate-readme) (a [verb](https://github.com/verbose/verb) generator), please don't edit the readme directly. Any changes to the readme must be made in [.verb.md](.verb.md).)_
