What can Angular 1.x do to a better module system integration?

[franleplant]

Right now, since Angular 1.x has a built in module system, integration with other module systems (AMD, Common.js, ES6) while possible, is rather full of boilerplate and it feels like a hack.

Is there any plans to improve this in Angular 1.x branch?

Thanks!
Fran

[vitaly-t]

Usually such comments are followed by suggestions, otherwise - what's the point?

I know only one but very solid approach to a mixed modulation where AngularJS is used via Browserify. As far as I know, this is the best approach that exists today, and there are a few articles that can be found about it, like this one: https://blog.codecentric.de/en/2014/08/angularjs-browserify/

Or do you think that this is also a hack? Then come back with a better solution, surely the Angular JS society will appreciate your contribution.

[franleplant]

Hi @VitalyTomilov, thank you very much for you response.

In your link I found this npm package that looks nice: https://www.npmjs.com/package/angular-bsfy,
and also the entire post is really descriptive.

The reality is that, while I enjoy very much browserify, and Angular for that matter, we can't get rid of the situation where we have 2 module systems. Also, using Karma and the default Angular testing tools and ways, tends to be tricky with this approach (not so much with Require.js)

Maybe Im not the only one feeling this and we can think together, because I actually don't have a solution for this right now :)

Maybe one option will be to hack around the injector to isolate it from the module system and thus integrate it with Common.js's modules.

[vitaly-t]

The only way for libraries like AngularJS to support third-party modulation or any third-party plug-ins for that matter, is by implementing optional overrides that allow fully custom functionality.

In case of modulation, I believe it is possible to override Angular JS dependency injector with a custom function. It would only take someone willing enough and knowing enough about Angular JS to provide such support, to make it user-friendly, so it can be achieved with a simple function call to set your own dependency resolver.

It's all just an educated guess, I haven't used Browserify enough to know for sure if it will work.

[caitp]

https://groups.google.com/forum/#!topic/angular/i5by29Okh48 would be a great thread for you to comment on WRT improving angular's module system integration.

We want to make the npm release do commonjs, but it's more work to figure out how we're going to fit the rest of the pieces together. So, comments are welcome.

In the mean-time, without a strong suggestion for action, this isn't very actionable so I'm going to close this. But input on improving the module story is welcome and I strongly encourage you to voice your opinion on that thread.

[franleplant]

Thanks @caitp and @VitalyTomilov for your help, I will continue my work on that thread you mentioned.

I believe that this is essential for Angular, since the Angular's module mechanism is just not enough for big applications.

[vitaly-t]

I've done some huge applications to argue the opposite that the available modulation is sufficient.

But there is always room for improvements ;)

[franleplant]

@VitalyTomilov that is very subjective, it depends on the conventions adopted by them team, and how good they are, but Angular's module system by it self can become very obtrusive.

I have seen big Angular applications in which unfortunately neither good conventions have been followed nor they have been followed consistently, and thus, developers have a hard time finding their way through the code.

Of course, devs are partially to blame here, since they've done things in not the better way, but I believe that the idea of a framework is to avoid as much as possible the developers shooting in their own foot.

And that is way, a more standard, full featured, module system could bring some clarity to the game, just for the sake of an example, compare the two:

angular.module('main', ['mod1', 'mod2'])

#main.js
var mod1 = require('./path/to/mod1');
var mod2 = require('./path/to/mod2');

The Angular way does not tell you anything about the module but the name, which in a big project can lead to not knowing where the module is.

Another thing is that Angular module system does not provide builds, and thus, you need to keep a list, potentially big, of <script> tags in your html (or in a configuration file).

My idea haven't had that much success on the email thread that @caitp suggested, nevertheless I'd like to experiment on this idea, I let you know what I come with so maybe you can provide feedback.

Thanks a lot for your time!
Fran

[pkozlowski-opensource]

@franleplant I think that modularity is a very important topic so it is great that you are willing to look into it. While doing your investigations, though, please keep in mind the following:

• CommonJS is not the only module system and ES6 modules are going to change the problem space considerably
• Big part of the current module system is linked to the testability story and the DI container - we don't want to loose any benefits here and I must say that I haven't seen any satisfying testing workflow with CJS so far (or at least not as good as we do enjoy with the current approach)

[pkozlowski-opensource]

One more thing: we should be really precise and make sure that we don't force one module system / workflow on all the users. For example, I find this remark odd:

Another thing is that Angular module system does not provide builds, and thus, you need to keep a list, potentially big, of <script> tags in your html (or in a configuration file).

Actually, what you can do is to simply concatenate all the files and I'm must say that I'm quite happy that AngularJS isn't forcing any build / packaging tool on me.

In short: this is important and quite complex topic in the fast changing context (ES6 modules) so we need to be careful as not force one way of working here.

[franleplant]

@pkozlowski-opensource agree with you on everything you say, specially in keeping the DI intact and that CJS and karma testability is rather awkward.

I like CJS, but ES6 should work well enough with this approach.
The good thing is since there are a lot of transpilers from ES6 to ES5 we can benefit from creating a simple solution for ES6 and let the devs compile it to AMD or CJS.

The one thing I disagree is about the list of script tags:

• Of course concatenating is necessary, and we do it
• You still need a list of files nevertheless (if you create a good set of standards you can solve it with a simple reg exp, but that is another thing entirely)

Thanks!
Fran

[pkozlowski-opensource]

@franleplant I'm not sure what is to agree / disagree about <script> tags here - in all the apps I was working on there is precisely one <script> tag for the entire app that loads all the JS + JSified templates. Example here: https://github.com/angular-app/angular-app/blob/second_edition/client/gulpfile.js#L98-L115. Once could easily add libraries to this one concatenated file but those are probably better loaded from a CDN.

Once again, there are many workflows and build systems out there are people will naturally have different preferences. But I don't think that current version of AngularJS forces anyone to use multiple <script> tags for application deliverable - this is the thing I wanted to underline.

[franleplant]

The script tag is just and example, the main point is that you usually need to maintain an ordered list of js files to load on the page, weather it is made with script tags or a configuration file.

If you app fits, you can create a nice reg exp to match most of the need source files, but you still need to keep some degree of order.