Creating a module twice fails silently

[ghd3v]

angular.module('foo', []).directive('bar', ...);
angular.module('foo', []).filter('baz', ...);

will cause the first directive registration to be lost.

[petebacondarwin]

This is by design - you should be able to replace a module with a new one,
particularly useful in creating test mocks.

This is one reason why I tend to use exactly one module to one file.

I agree though that this is an easy mistake to make and perhaps there
should be a more explicit API, perhaps:

angular.module -> creates a new module and errors if the module name
already exists
angular.replaceModule -> replaces a module with the given one and errors if
the module name does not already exist
angular.addToModule -> reopens a module to add components to it; errors if
the module name does not already exist. (This is equivalent to the current
angular,module without providing dependencies)

[nahue]

+1 i was having this problem and i didnt know why :)

[ifitzpatrick]

+1 for a more explicit api

[geddski]

@amirhyoussefi you'd be better off creating a module in one file, say foo.js and adding things to it in other files. Use angular.module() with just one parameter and it will fetch the already created module rather than overriding it. For example:

foo.js

angular.module('foo', []); 

bar.js

angular.module('foo').directive('bar', ...);

baz.js

angular.module('foo').filter('baz', ...);

This pattern also has the benefit of not needing to introduce another global variable for your module. Yay.

[ghd3v]

If we can provide a warning when it happens that would be great. An IDE can flag this (to say the least).

@nah I had the same problem as the issue was hard to debug.

[anjo]

Why not simply add to the dependencies? I.e. you would have:

angular.module("foo", null, [some new deps])

and use null as a flag to add to the deps instead of replacing. The way it is now it's really a bitch to find out where the problem is when you suddenly get a blank page and nothing works

[anjo]

@GEDDesign but the downside is that you need to remember to init your module in advance of calling angular.module('foo'). You won't really run into an error, but things won't work when you test.

Another downside is that you can't add to the dependencies when you actually declare them, ie. when you have a larger module, you might want to define your dependency with your service and not with the module:

angular.module("foo",["stuff this service depends on"]).service(...)

so it will get added to later on.

[qrow]

I run into this problem and could'n understand what i did wrong, there were no error and app just stopped working because i override whole module together with routes.

This is bad experience for people that starting with angular as information about possibility to override module is hidden in documentation in one of parameters description.

If there is no plans to change API, then maybe warning could be written to console, because i think this will be common mistake for beginners.

Also documentation of module function if wrong in "Returns" part:

Returns
{module} – new module with the angular.Module api.

because it returns new module only if you specify dependencies, in other case it returns existing module.

[btford]

As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months.

Please try the newest versions of Angular (1.0.8 and 1.2.0-rc.1), and if the issue persists, comment below so we can discuss it.

Thanks!

[iven]

It wastes me half a day to find this issue page. I could just get useless error messages like: 'unknown provider', or 'circular dependency'.

You should really consider using new APIs like:

var newFooModule = angular.module.create('foo');
var existingFooModule = angular.module.get('foo');

or provide a warning message in the console.

BTW, I'm using 1.2.0-rc2.

[petebacondarwin]

I agree
On 12 Oct 2013 09:21, "Iven" notifications@github.com wrote:

It wastes me half a day to find this issue page. I could just get useless
error messages like: 'unknown provider', or 'circular dependency'.

You should really consider using new APIs like:

var newFooModule = angular.module.create('foo');
var existingFooModule = angular.module.get('foo');

or provide a warning message in the console.

BTW, I'm using 1.2.0-rc2.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1779#issuecomment-26193471
.

[hiddentao]

I find that there are two fundamental requirements that the current angular.module API doesn't easily satisfy:

1. Being able to split up a module into multiple files so that I can keep a clean codebase, without having to worry about making sure I call angular.module(name, deps) before I call it without the deps parameter.
2. Being able to easily add dependencies to an already created module (something that follows on from the previous point, since I'd like to list dependencies in the context in which they are being used).

I wrote a decorator for angular.module which satisfies the above two requirements, but then breaks the design requirement that an existing module can be completely overridden (e.g. for testing).

Looking at the API we could change the single-argument version of angular.module() such that it automatically creates the module if it doesn't already exist but then this breaks a bunch of tests which check that invalid module names result in error thrown during the app initialisation process.

So for now I propose just adding a new API which makes it easy to append to the list of dependencies:

var mod = angular.module('name');
mod.dependencies(['dep1', 'dep2']);

I'll work on raising a pull request for this.

[j-walker23]

@hiddentao if you split up everything into separate modules and import them into their direct parents then the current api works just fine and satisfies all problems. That is the way i went after trying to declare parts of modules in separate files. Just have separate modules in separate files, and import when needed. One module per file.