Question

I’ll try to summarize a few steps and ask a question after

1. underscore.js failed to install when developing a 3rd-party javascript component (as described here: Underscore.js and noconflict). my code included the following line to avoid collisions of different versions of underscore.js:

   window.$MyUS = _.noConflict();

2. when looking into the underscore.js code, it was found that if exports or module.exports is defined, than the _ variable will become a member of exports or module.exports. It just happened (in browser, not in Node.js of course).

3. I’ve tried to save the exports object aside and delete it before loading underscore.js and restore it right after calling noConflict(). However, when calling delete exports, I’ve got false, which means that exports can’t be deleted.

4. I’ve found two member functions in exports object: compile() and compileToString(). By looking into their implementation I’ve found LF references which perhaps refer to livefyre Javascript API (http://www.livefyre.com/docs/javascript-sdk-reference)

Which is the better way to resolve the conflict? I see the following options:

1. Modify the underscore.js code so that it won’t try to install itself into exports object.

2. Let underscore.js to modify the exports object and hope that nothing wrong will happen on any site. In that case I will need to re-write the window.$MyUS = _.noConflict(); line like this:

   window.$MyUS = .noConflict || exports..noConflict() || … ; // sanity checks omitted for clarity, obviously the production code must be more robust

If you need any more info – please ask.

Answer 1

The answer, I think, is simple: fork underscore on GitHub and add a simple patch that refuses to attach itself to exports if window exists, and submit a pull request.

That way everyone benefits: you don’t have re-apply your patch every time you upgrade your copy of underscore and others don’t have to deal with that problem, either.