K3k3n·Nov 6, 2013
I believe this is actually promoting an anti-pattern, and will result in code that is hard to test and which isn't expressly modular.
From the source[1]:
* core.js creates the "myLib" object
* module1.js & module2.js augment "myLib" with additional properties
* myLib.js takes the final, augmented object, and assigns it to a global variable
There are many problems with this setup, but the main one is going to be that the module1.js/module2.js both alter the module defined by core.js. The augmentation is permanent (until page reload).
So, what you end up with is a situation where you cannot include module1/module2 without first including core; this is not modular code and will make testing those modules more challenging and brittle -- you effectively can't test them independently. Rather, you'd have to test the relevant properties on the my
Read the rest
Lib object or stub-out myLib with a mock.
When working with modules, you typically don't want to build up some giant, monolithic object -- rather, you should be pulling in modules as you need and using them independently. Each module should return it's own object, which you can freely use within the context of another module but which has no adverse side-effects on any other modules.
1. https://github.com/sahat/requirejs-library/tree/master/src