multiple modules with the same name

Maciej Jaros egil at
Mon Jan 27 18:07:19 PST 2014

Sam Tobin-Hochstadt (2014-01-27 23:50):
> This is absolutely necessary for polyfilling.
> 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.

Keeping your syntax you could declare:
<script type="module" name="jquery_1_17" src="jquery1.js"></script>
<script type="module" name="jquery_2_1" src="jquery2.js"></script>

Then the script that need 1.17 uses import:
import $ from "jquery_1_17";
And script that need 2.1:
import $ from "jquery_2_1";

But to my understanding a loader could be created that could 
automatically resolve something like (i.e. per some convention it would 
now where to find best CDN for each jQuery version):
import $ from "cdn.jquery/2.1";

Or just a full URL:
import $ from ""

I actually like that syntax much more then declaring stuff in HTML. Not 
sure if that will be possible though.

> Sam
> On Mon, Jan 27, 2014 at 5:45 PM, John Barton <johnjbarton at> wrote:
>> What is the use case for allowing registration different modules under the
>> same name? IMO should be an error.
>> jjb
>> On Mon, Jan 27, 2014 at 2:32 PM, David Herman <dherman at> wrote:
>>> On Jan 27, 2014, at 2:18 PM, Marius Gundersen <gundersen at> wrote:
>>>> So then there would be two versions of the same module, and a module
>>>> could get access to both these modules at the same time. For example, if
>>>> ModuleB, which depends on ModuleA is loaded and linked, and later ModuleA is
>>>> redefined, then ModuleC could depend on both ModuleB and ModueA, and would
>>>> get (indirect) access to two versions of ModuleA. Is this problem
>>>> preventable?
>>> It's important to be able to modify module registration for things like
>>> polyfilling. But that doesn't mean it's something people should do in
>>> general. Note that Jason only gave you an answer in the context of the basic
>>> module loader semantics; he didn't say what will happen in the HTML
>>> semantics. In particular, we can make it an error for there to be two
>>> definitions of the same module name in the same HTML, a la:
>>>    <script type="module" name="jquery" src="jquery1.js"></script>
>>>    <script type="module" name="jquery" src="jquery2.js"></script>
>>> I'm inclined to call that an error, and require imperative modifications
>>> of existing module registrations to use imperative code.
>>> Dave
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list