So, this proposed patch isn't really the same thing as the existing Node.js export. With the current version, you write:

var _ = require("underscore");

With your version, you would have to write:

var _ = require("underscore")._;

Do you have any facility in Titanium for setting the exports object so that the former will work? Are you planning to introduce a "module" object?

As far as I can tell, var _ = require("underscore") will still work in Node; this patch simply adds support for CommonJS environments that don't support the non-standard module.exports property.

Oh, certainly -- but having to require it in two different ways, depending on the flavor of CommonJS ... is the kind of thing that CommonJS is supposed to fix. Ideally Titanium does (or will) provide a way to set the exports object directly for libraries that export a single object.

module.exports is not part of the CommonJS spec, it's a Node.js specific flavor of CommonJS handling. When the CommonJS spec actually includes module.exports Titanium will assuredly support it. In the meantime, it would be nice to have a spec-compliant option for exporting underscore.js as a module.

Maybe I'm missing something, but couldn't this be fixed simply by attaching all properties of _ to the exports object directly? After all, underscore doesn't simply "export a single object"---it exports a large number of functions. The packaging under a single _ namespace is an artifact of the browser where you try to avoid polluting the global scope with namespacing.

@DomenicDenicola ;) You're missing something: https://github.com/documentcloud/underscore/blob/master/underscore.js#L49 Underscore is a function, not just an object.

@tonylukasavage -- Unfortunately, the CommonJS "spec" has been dead in the water for a long time now. (Just my opinion, but ...) Regardless of what the spec does or doesn't do at some time in the future, would you consider adding some mechanism to export a single object/function, like Underscore? I don't much mind if it's module, or something different.

Doh! Yes, CommonJS Modules/1.1.1 has sadly failed to provide a way to export functions. I've got my own feelings on that whole kerfluffle, but I'll stand back and let the OP take over from here so as to avoid any further blunders :)

@jashkenas - That may happen at some point, but in the meantime would it not be beneficial to underscore.js to support CommonJS implementations that follow the spec? It's a pretty unobtrusive modification that would make its adoption much easier.

Sure, perfect being the enemy of the good and all that.

@jashkenas - So whadda ya say? We'd love to start encouraging Titanium devs to use this library.

Yep -- I've merged in your change with a tweak.

Off topic, but aren't there still problems with Titanium devs trying to use Underscore, due to Underscore not following JSLint rules? Or has that changed recently?

JSLint is an optional validation method with Titanium builds, and not the default one. it's only really an issue if the developer makes it one.

I think that _._ = _ should be included somewhere, so that if you do require("underscore")._ inside of Node, you don't get undefined.

If you're complaining about not wanting to use module.exports because it isn't standard, then exports._ should be. You're trying to fix an incompatibility due to a nonstandard property, with another nonstandard property.

@tylermwashburn Yes, it does that.

@jashkenas So it does. I probably should've checked about that first.

FYI, we have an open issue against not being able to assign variables directly to the exports object. There's some discussion as to whether or not it is provided for in the spec - probably it is not, as it would be a liberal reading of the spec document. But we still need to have something.