> 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); }
define(...);
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) {
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
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
