CommonJS - A YAGNI Based "require"

I am very busy these days with my last (hopefully) moving into my new and completely empty rented flat ... and while I am building home utilities and preparing my last post about A Better JS Class, with some extra case where common libraries fail with their parent implementations, I would like to quickly share this require function I wrote days ago but just recently came back in front of my eyes.

Why require

In CommonJS we have different techniques and agreement about how developers should structure/organize their namespaces and libraries.
The first common function adopted from CommonJS "followers" is the require one. This function aim is to load once, and runtime, a namespace, allowing scripts loaded via this function to define exported properties/variables or methods/functions.

// file main.js
var $ = require("jquery").$;

// file jquery.js
// let's imagine jQuery library has this piece of code inside
if ( typeof exports != "undefined" ) {
    // export the library as dollar function
    exports.$ = jQuery;
}

The require Function

var require = (function (
    global,         // global scope object (not necessary window)
    cache,          // object with loaded namespace to avoid reloads
    exports,        // variable name (better compression)
    ActiveXObject   // property name (better compression)
) {
    /*!WebReflection:MitStyle*/
    function request(namespace) {
        // create the xhr object, no need to optimize
        // this check is nothing compared with the time
        // required to load and evaluate the resource
        var xhr = new global[global[ActiveXObject] ? ActiveXObject : "XMLHttpRequest"]("Microsoft.XMLHTTP");
        xhr.open(
            // method
            "GET",
            // path replaced
            (require.root || "") + "/" + namespace.replace(/\./g, "/") + ".js",
            // synchronous
            false
        );
        // send request
        xhr.send(null);
        // assign the runtime created export object
        // with the required namespace
        return (cache[namespace] = Function(
            exports,
            // the text will be evaluated in a global function
            // it can register exported variables/methods
            // simply writing:
            // export.$ = {};
            // so that require("mylib").$; will always
            // point to the correct property
            xhr.responseText + ";return " + exports
        // be sure the function is executed
        // with a global context (the this reference)
        ).call(global, {}));
    }
    // if namespace has been loaded already
    // the associated export object will be returned
    // otherwise the precedent function will be
    // executed
    function require(namespace) {
        return cache[namespace] || request(namespace);
    }
    // the exposed function
    return require;
}(this, {}, "exports", "ActiveXObject"));

Above piece of code fit into about 350 bytes once minified, less than 260 bytes gzipped ... sweet, isn't it?
Bear in mind if we need a root, we can simply add it via require.root = "./my/js/path"; without last slash after the final folder (e.g. require.root="." to load from the current one).

YAGNI In Details

For those unable to understand the acronym, YAGNI simply means "Ya ain't gonna need it".
The YAGNI behind my proposal could be summarized in this way:

• server side frameworks have their own native require, no need to fully replicate it, it's already there
• simply Ajax, if the browser does not load via other protocols and you are testing, enable file: via about:confing/strict or the local support for XHR
• the most used case is the one we all know, require function will be there, as global one, and module object is not yet important (CommonJS is constantly updated as well)
• A well organized namespace will improbably affect object properties (e.g. Object.prototype["my.name.space"] does not make much sense). No need to use hasOwnProperty, specially not the object itself one, since Object.prototype.hasOwnProperty could be redefined without problems and most probably this is an edge case more dangerous than the prototype["my.long.namespace"]

All these points are better considered in another version I did not know, the one from David Flanagan.
In any case, we should consider this valid point of view about require and JavaScript client, from Lucas Smith.
At least now we have more alternatives in the field, with this one that should simply bite others at least for size, and for common case reliability.
Enjoy!