jashkenas/backbone — pull request #3144 by jmeas (2014-05-06 22:29:15+00:00)
Title: Places Underscore as a peerDependency

This specifies Underscore as a peer dependency. This is important for people who use CommonJS because it solves the issue of **double Underscores** in your compiled files.

Here's the chain of events that lead to the problem:

1. Backbone lists Underscore as a dependency
2. Because of this, `npm install` includes a nested version of Underscore within Backbone's node modules
3. Backbone `require`s in Underscore
4. CommonJS builders like Browserify and Webpack will pull in the instance of Underscore that is nested within Backbone for this `require`
5. In another file (maybe in your app) you `require` Underscore. Note that this only works if you specify Underscore a dependency, or peer dependency, which installs a **second** Underscore in your app's `node_modules`.
6. CommonJS builders pull in the second instance of Underscore for this other `require`.
7. You now have two Underscores in your built file

By specifying Underscore as a peer dependency you acknowledge the fact that Backbone relies on Underscore but users will **most likely have other things that want to use Underscore**. This makes it so there is only one Underscore in your node modules – in the root – and every library will require in the same one.

So what's the solution right now? Either writing hacky shims to force Backbone to use a particular Underscore or telling your compiler to treat it as it isn't CommonJS-ready. Neither of these are good fixes, I think.

This [blog post](http://blog.nodejs.org/2013/02/07/peer-dependencies/) describes peer dependencies in terms of plugins around a central library, but I think that might be limiting the scope of peer deps.

Consequences of this change:

- Using two different Underscores (one for Backbone, one for your app) is much harder
- For folks trying to do that they will need to resolve the dependency conflict, which can be annoying