Creating a module with the same name of the app breaks everything about mean

[rschwabco]

We should probably disallow creating module that has the same name as the app... Sounds like a bad idea to me. Opinions?

[frederik]

Agreed. In any case it'd be interesting to know the cause tho

[aarosil]

Strange... it worked fine w/ 'fake'. It's something w/ the name 'docs' itself.

[svallory]

@aarosil I actually discovered the error when trying to create a module “doctors” inside my app, named Doctors.

As to wether it’s a bad idea or not I’m really not in a place to judge right now. But it made sense to my case and it was really annoying to figure out what the problem was and even more so having to change the name of the app or the model to work around it.

[revdave33]

Just a quick look at the code (I might be wrong). Since the main angular module is set to the app name, it uses the module setter in public/js/config.js. That is where the injector sets up all the dependencies (angular.module('appname', [dependency modules]) . Once a module is set, you need to use the getter version of module to add to that (angular.module('appname')). If you use the setter version again you mess things up (I learned that). So when the meanjs:crud-module yeoman process tries to use the same module name as the the appname, it screws up the injected modules for the overall angular module.

Two options: either prohibit a crud-module with the same name as the app, or return to the original way of naming modules with prepending the appname... mean.core mean.article mean.mean etc. (unless that breaks something in a way I'm not seeing)

With the valid example @svallory gives, I would think we would prefer not preventing the developer from doing what makes sense to them in their project. and going the second route.

[amoshaviv]

@svallory indeed an issue, we'll take care of it in the next version.
@revdave33 you're right, I also prefer the second option.