Hide third-party libraries from global namespace #2

gersongoulart opened this Issue Oct 25, 2012 · 6 comments

2 participants


Hey @petermichaux!

First of all congratulations for maria. It's an amazing project. Small, clean and supper easy to learn. I simply love it.

This issue is just a simple suggestion for improvement: Shall the final build of maria.js be wrapped in a Immediately-Invoked Function Expression (IIFE), exporting only the maria namespace and hiding all the other libraries from the global namespace? That would make for a cleaner implementation (in my opinion anyways).



Hi @gersongoulart,

I'm glad you are enjoying Maria and thanks for your positive feedback. Do you have any example code you could share?

Regarding your suggestion, would making that change impact your use of Maria in any way? If it is just for purity, I could add a special build to the makefile that adds this to the top

var maria = (function(){

and this to the bottom

return maria;}());

Is that what you're thinking?


Hi! I don't have any example quite yet, I just found out about Maria a couple of days ago and I'm doing some experiments with it, but if it works well for me I want to use it in a really large web application sometime soon. Of course I wouldn't mind sharing some bits and pieces with you as soon as I have something tangible...

About this suggestion, yeah it's just for purity. I personally like when 3rd-party solutions do not pollute the global namespace. Any regular project already have dozens of things there that shouldn't be there :P. And yes, what I did was pretty much the same thing as you're suggesting (I don't think it makes any difference really):

(function( exports, undefined ) {

...and in the bottom:

  // Expose maria to the global object
  exports.maria = maria;

})( this );

Having it as part of the build is a terrific idea.


This ticket has given me quite a bit of food for thought. I already made some commits because of this issue to simplify how namespaces in all the various projects are created.

What I'm considering now is not importing the other libraries into the maria namespace. This will help if the third-party namespaces are not hidden and the third-party libraries are modified via plugins to those libraries.

The third party plugins could also be hidden as discussed in this ticket as an alternative but it would actually reduce the flexibility of everything if done without care.

Seeing as this is not an emergency issue, I'm taking time considering things carefully.


Pretty good point you made. I wasn't considering the fact that those libraries can also be extended via plugins. Now I got some food for thought...


This ticket definitely gave me a lot to think about. This article was even part of the result: http://peter.michaux.ca/articles/early-mixins-late-mixins

I ended up resolving the issue the other way around: I made Maria more friendly to plugins for the dependencies of Maria. So the dependencies are not hidden but rather are useful now.

I suppose a build could still be made that hides the dependencies but that is more a matter of personal taste and purity rather than genuine necessity. If some actual necessity appears then we could reconsider.


The work on an AMD build of Maria in #4 needed the Maria code to be wrapped in a function. That means for the AMD build, the other libraries (i.e. Evento, Hijos, Grail, Hormigas, and Arbutus) are not visible for plugin extension. The AMD users can only modify the maria object via plugins. Due to this change, I'm reconsidering my comments in this ticket because all plugins should work for AMD users too. That means hiding the other libraries inside and immediately-invoked function expression and only making the maria object global is consistent with the AMD experience.

@petermichaux petermichaux reopened this Apr 16, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment