Change how CommonJS requires module

[renestalder]

To be honest, I don't have a clue how it is to make a JavaScript library available for consuming via Browserify/CommonJS/AMD.

But what I see so far, angular-cache is different from all other modules. It exposes the name on requiring instead of an object.

This is what it looks like when I'm using angular-cache in my app with Browserify

module.exports = angular.module('myapp.core', [
  require('angular-route').name,
  require('angular-moment').name,
  require('angular-ui-router').name,
  require('angular-cache'), // does not work with the .name property

  // Some other stuff
  require('../layout').name
]);

It's the only one module which does not expose its name via name property. Is there any good reason for this?

[jmdobry]

No, it's arbitrary, just like the convention of exposing an object that has a name property. The purpose of exporting a module object is so you can add things to it. There is no reason to add anything to the angular-cache module. The thing about Angular libraries, is that they register their services/directives/etc. with the dependency injector, you don't actually use exported code directly. The convention of exporting the name of the module was invented to save you 1 line of code per module, so you don't have to do this:

require('angular-route');

module.exports = angular.module('myapp.core', [
  'ngRoute'
]);

Angular-cache's way of doing it even saves you an extra 5 characters. There is nothing else to export but the name of the module, so why can't I just export the name directly, instead of nesting it under some object that has no other purpose?

I based what I did off of this blog post and the people in this thread who argued against exporting the whole module with a name property.

[renestalder]

@jmdobry Thanks for the links. Very interesting and since we use CommonJS not only for AngularJS, I never thought about the fact, that it may be used different in the AngularJS context.

Makes sense.