On Tue, Jan 28, 2014 at 2:13 AM, James Burke <jrburke at gmail.com> wrote:

> On Mon, Jan 27, 2014 at 3:14 PM, John Barton <johnjbarton at google.com>
> wrote:
> > On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt <
> samth at cs.indiana.edu>
> > wrote:
> >> Imagine that some browser has an ok-but-not-complete implementation of
> >> the X library, but you want to use jQuery 17, which requires a better
> >> version.  You need to be able to replace X with a polyfilled update to
> >> X, and then load jQuery on top of that.
> >>
> >> Note that this involves indirect access in the same library (jQuery)
> >> to two versions of X (the polyfill and the browser version), which is
> >> why I don't think Marius's worry is fixable without throwing out the
> >> baby with the bathwater.
> >
> >
> > Guy Bedford, based on experiences within the requirejs and commonjs
> worlds,
> > has a much better solution for these scenarios. (It's also similar to how
> > npm works).
> >
> > Your jQuery should depend upon the name X, but you Loader should map the
> > name X when loaded by jQuery to the new version in Loader.normalize().
> The
> > table of name mappings can be configured at run time.
> >
> > For example, if some other code depends on X at 1.6 and jQuery needs X at 1.7,
> > they each load exactly the version they need because the normalized
> module
> > names embed the version number.
>
> In the AMD world, map config has been sufficient for these needs[1].
>
> As a point of reference, requirejs only lets the first module
> registration win, any subsequent registrations for the same module ID
> are ignored. "ignore" was chosen over "error" because with multiple
> module bundles, the same module ID/definition could show up in two
> different bundles (think multi-page apps that have a "common" and
> page-specific bundles).
>

AFAIK ES-6 modules cannot be bundled (yet). But if/when they can be bundled
this is an argument for silently ignoring duplicates

>
> I do not believe that case should trigger an error. It is just
> inefficient, and tooling for bundles could offer to enforce finding
> these inefficiencies vs the browser stopping the app from working by
> throwing an error.
>
> It is true that the errors introduced by "ignore" could be harder to
> detect given that things may mostly work. The general guide in this
> case for requirejs was to be flexible in the same spirit of HTML
> parsing.
>

Since the imperative API through the Loader object uses promises, there is
the option to reject the promise rather than throwing an error. This would
let the developer handle the duplicate if they want to, but wouldn't
require wrapping the API calls in try{}catch.

>
> Redefinition seems to allow breaking the expectation that the module
> value for a given normalized ID is always the same.
>
> When the developer wants to explicitly orchestrate different module
> values for specific module ID sets, something like AMD's map config is
> a good solution as it is a more declarative statement of intent vs
> code in a module body deciding to redefine.
>
> Also, code in module bodies do not have enough information to properly
> redefine for a set of module IDs like map config can. Map config has
> been really useful for supporting two different versions of a module
> in an app, and for providing mocks to certain modules for unit
> testing.
>
> Given what has been said so far for use cases, I would prefer either
> "ignore" or "error" over redefinition, with a preference of "ignore"
> over "error" based on the above.
>
> [1] https://github.com/amdjs/amdjs-api/wiki/Common-Config#wiki-map
>
> James
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140128/adb6d00a/attachment-0001.html>

On Tue, Jan 28, 2014 at 2:13 AM, James Burke <jrburke at gmail.com> wrote:

> In the AMD world, map config has been sufficient for these needs[1].
>
> As a point of reference, requirejs only lets the first module
> registration win, any subsequent registrations for the same module ID
> are ignored. "ignore" was chosen over "error" because with multiple
> module bundles, the same module ID/definition could show up in two
> different bundles (think multi-page apps that have a "common" and
> page-specific bundles).
>

AFAIK ES-6 modules cannot be bundled (yet). But if/when they can be bundled
this is an argument for silently ignoring duplicates

> I do not believe that case should trigger an error. It is just
> inefficient, and tooling for bundles could offer to enforce finding
> these inefficiencies vs the browser stopping the app from working by
> throwing an error.
>
> It is true that the errors introduced by "ignore" could be harder to
> detect given that things may mostly work. The general guide in this
> case for requirejs was to be flexible in the same spirit of HTML
> parsing.

Since the imperative API through the Loader object uses promises, there is
the option to reject the promise rather than throwing an error. This would
let the developer handle the duplicate if they want to, but wouldn't
require wrapping the API calls in `try{}catch`.