ES5 Module Systems (was: Alternative proposal to privateName.public)

Axel Rauschmayer axel at
Tue Dec 27 00:07:01 PST 2011

> This type of boilerplate may not be processed properly by AMD
> optimizers that insert module IDs into the define call when multiple
> modules are combined together. While the above may work with the
> requirejs optimizer, it is not guaranteed to work in the future. I
> still prefer the define() call is a non-property function call and not
> a call to an object method, to avoid possible conflicts with a module
> export value (uglifyjs has one such conflict).

I’d expect to remove my boilerplate either via an extra build step or via generic boilerplate support in the RequireJS optimizer (“remove all lines where '//amd-boilerplate' appears”).

I’ve chosen my format after considering two alternatives (which both had disadvantages).

Alternative 1:
    if (typeof define !== 'function') { var define = (require('amdefine'))(module); }

The above code relies on a quirk of of `var`. If you wrap it in an IIFE then it will stop working (because the inner var define will always shadow an outer value).

Alternative 2:
    (function (define) {
    }(typeof define === 'function' ? define : require('amdefine'))(module));

Here the boilerplate appears both before and after the AMD code. That’s more intrusive and harder to copy/paste.

> In that message I also mention encouraging the use of the "amdefine"
> adapter module in Node. Use of this module will help test drive a
> define() implementation that could be integrated into Node later, and
> by having Node packages use the module, it would give Node committers
> a way to scan the package.json info to find out if define() use is
> used enough to warrant consideration in their core.

I’m still examining all available, but eventually a campaign might be in order. 

Dr. Axel Rauschmayer
axel at


More information about the es-discuss mailing list