1.0.6 Breaks if you use Lodash

[kahnvex]

Version 1.0.6 broke our build because it does a require('underscore').

We use Backbone.ModelBinder with Browserify, and Browserify can't resolve Underscore because we don't use it, we use Lodash.

[platinumazure]

@kahnjw Don't know if this will help, but...

According to this RequireJS issue, it seems one way to work around this is to set up a mapping in your AMD config to map "underscore" to the "lodash" module. Is there an equivalent in Browserify?

[alexkalderimis]

You can specify module->module mapping for browserify with browserify-shim

[platinumazure]

@alexkalderimis Thanks for that insight.

Is it fair to say in general that there's no real way to control it in this repository? I feel like the only way we could really "fully support" Lodash (or similar) is by having some sort of custom build tool that generates an AMD script with the appropriate module names specified in the require call. I feel like trying to "detect" Lodash or other alternatives for the dependency modules, even if it were supported by RequireJS/browserify/etc., would be an anti-pattern. Would you agree?

If that's true, then I think we really have no choice but to step back and agree to view AMD dependencies as mere "named modules", with certain behavior expectations (i.e., the implicit contract formed by the methods we invoke from each of those modules), and state that users simply have to fill those named module dependencies with shims or name mappings (or, you know, the actual module, if that works for them).

And all that said, if there aren't any problems with my line of reasoning, I don't see much point in keeping this issue open.

[kahnvex]

I feel like the only way we could really "fully support" Lodash (or similar) is by having some sort of custom build tool that generates an AMD script with the appropriate module names specified in the require call.

Or use dependency injection? To be honest I think it is a much cleaner and more pragmatic way to accomplish dependency management for FE code. And a much better way to solve this problem. When every bit and clock cycle counts, nobody can afford to double bundle underscore compliant libraries. Dependency injection gives consumers freedom to inject their own optimized compliant interfaces. Why should ModelBinder require you to be using underscore when Backbone doesn't even do that?

[amakhrov]

Doesn't Backbone itself have hardcoded require('underscore')? What's the point in making a plugin for Backbone more flexible than Backbone?

@kahnjw how are you solving this issue with Backbone?

[kahnvex]

Doesn't Backbone itself have hardcoded require('underscore')? What's the point in making a plugin for Backbone more flexible than Backbone?

Yes it does, but it is executed iff typeof exports !== 'undefined' evaluates to true. And (forgot about this part) we're using a shim to include backbone, so exports is undefined in that scope. In any case, the main reason this upset me is that it was a change made in a patch update, and created issues in our production environment.

I'm all for improving how this library, and backbone itself, manage their dependencies. With that said we've since moved away from ModelBinder and Backbone on new projects, and it seems like this isn't gaining much support. Closing it.