Modules: use of non-module code as a dependency

Azer Koçulu azer at
Mon Jul 9 16:52:36 PDT 2012

Here is an example of what I recommended;

    package jquery ties window.jQuery

On Sun, Jul 8, 2012 at 4:20 PM, Azer Koçulu <azer at> wrote:
> 4) being able to bind variables/object paths to virtual package names.
> this is what OneJS ( provides to its
> users and it's being used for documenting and optimizing the code.
> On Sat, Jun 30, 2012 at 4:16 PM, James Burke <jrburke at> wrote:
>> On Sat, Jun 30, 2012 at 11:19 AM, David Herman <dherman at> wrote:
>>> I'm curious why you didn't include what seems like the most straightforward answer to me: jQuery continues to work as it did before, and just like always, you include it via a script tag and subsequently access it as a global:
>>> <script src="jquery.js"></script>
>>> <script>
>>> ... $('#foo').blah().blah() ...
>>> </script>
>>> I'm wondering why you didn't include this option -- is it just because jQuery is a special case that creates globals, whereas you also want this to work for modules that don't create globals?
>> This is not just because it is jQuery, it is just for any baser
>> libraries a user may use that cannot update to new keyword syntax. One
>> of the options above was that jQuery could do a runtime check for a
>> Loader API like System.set(), but not do the new keywords.
>> One of the problems a module system should solve is automatic
>> dependency resolution. It should not require a developer to manually
>> map out the dependency tree and load *some* of them in another loader
>> system (plain script tags in this case) before using them. The harmony
>> module system will look bad, particularly since this is not an issue
>> with existing JS module systems.
>> James
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list