multiple modules with the same name
egil at wp.pl
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 "http://code.jquery.com/jquery-2.1.0.min.js"
I actually like that syntax much more then declaring stuff in HTML. Not
sure if that will be possible though.
> On Mon, Jan 27, 2014 at 5:45 PM, John Barton <johnjbarton at google.com> wrote:
>> What is the use case for allowing registration different modules under the
>> same name? IMO should be an error.
>> On Mon, Jan 27, 2014 at 2:32 PM, David Herman <dherman at mozilla.com> wrote:
>>> On Jan 27, 2014, at 2:18 PM, Marius Gundersen <gundersen at gmail.com> 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
>>> 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.
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss