Don't expose jQuery to window with AMD

[ryanflorence]

Ticket: http://bugs.jquery.com/ticket/10545

One of the great features of AMD is not touching the global namespace outside of require and define.

I don't want my team and I to use jQuery w/o deliberating requiring it into a module, additionally the RequireJS optimizer will know to include it.

For people requiring from a CDN, they just configure the paths, no need for a global jQuery object in an AMD environment:

var require = {
  paths: {
    "jquery": "http://code.jquery.com/jquery-1.7b2.js"
  }
};

[rwaldron]

@rpflorence can you file a ticket for this? http://bugs.jquery.com

[ryanflorence]

Ticket filed, added to first comment - http://bugs.jquery.com/ticket/10545

[ryanflorence]

Ping: @jrburke

[timmywil]

I agree this is the way it should be done.

[ryanflorence]

Removed from core.js because outro is where the jQuery object is "exported".

[addyosmani]

Agreed - ticket marked as valid. http://bugs.jquery.com/ticket/10545

[rwaldron]

@rpflorence thanks for filing the ticket :)

[jrburke]

I appreciate wanting to do this, but I'm not sure it is safe to do so given how much jQuery is used. One of the reasons the original AMD patch was pulled from 1.6 was concerns about how multiple versions of jQuery would interact with AMD, since some pages can inadvertently load more than one version of jQuery.

The define.amd.jQuery was added so that an AMD loader could broadcast that it knew there could be a few jQuerys loaded on a page and had mitigations so that the developer who was using an AMD loader could receive the correct one. In requirejs, there is multversion support and also a way in the config to specify only accepting a specific version of jquery in the define call.

My concern with this patch is that a third party lib that uses jQuery is loaded on a page with an AMD loader. This patch would mean the AMD loader would get that version of jQuery but the third party lib would not see a global jQuery object, and errors would occur. What is worse, the AMD loader may just outright reject that jQuery registration call if it is looking for a different jQuery version.

If jQuery were not as popular as it is now, or started off always with this logic, it would not be that much of a concern. In fact if it was any other JS library out there, the approach in this patch is the right one. However, for jQuery, I believe it will lead to errors and elevated support requests.

I do not have a complete understanding of the magnitude of this hazard, the jQuery core folks can answer that better. But this concern is what lead me doing the AMD registration as it is today.

For AMD folks that do not want to export a global, they can do an optimized build and call jQuery.noConflict() to get this effect (with the build there should not be a window when the AMD-desired jQuery interferes with another one in the page). Not the ideal, but sometimes these kinds of things are needed to upgrade the web.

It would be good to get feedback on what people think is the relative threat of problems as outlined above, but I think given jQuery's special status doing the dual registration is the less disruptive route.

[ryanflorence]

Thanks James, that's why I pulled you in, I was sure there might be some issues.

My concern with this patch is that a third party lib that uses jQuery is loaded on a page with an AMD loader. This patch would mean the AMD loader would get that version of jQuery but the third party lib would not see a global jQuery object, and errors would occur.

A quick jQuery.noConflict() in the main.js is the safest bet, for sure. However, I believe that if somebody is building their app with AMD, they will be aware of this. I feel like if you're going to support AMD, support AMD all the way, incentivizing third party libs to support AMD as well.

I'm also curious what the repercussions would be and (hope) they're worth it.

[jrburke]

A quick jQuery.noConflict() in the main.js is the safest bet, for sure. However, I believe that if somebody is building their app with AMD, they will be aware of this. I feel like if you're going to support AMD, support AMD all the way, incentivizing third party libs to support AMD as well.

The problem is the code change hurts people that are not opting in to AMD, which at the moment is a larger set of people, and the error may be tricky for them to track down, indeed it can break code that no longer has an owner. I think, in jQuery's case, having the people embracing the future do a little bit more work is the less disruptive path, and maybe by a jQuery 2.0 the behavior could be changed to this logic of either/or.

But it would be good to get a read from the jQuery core members on their assessment of the risk. I would be happy to go this either/or path if the core folks felt the risk is manageable.

Maybe I am overestimating how much jQuery is used in third party code that ends up on pages, and maybe we just need to document how they can temporarily override define() while their bundled code executes to avoid the issue, then set back define() when done.

[timmywil]

I suppose jQuery.noConflict(true) is an easy solution. I would like to see it completely modular, but @jrburke's prediction of many support requests would certainly be true.

Given the sheer number of jQuery plugins, it would be difficult to require editing each one to conform to AMD. And yet, not impossible. If you're using an AMD loader, you already know how it works and I'm sure you already have several concerns if you're loading multiple versions of jQuery on the page.

Anyway, I'm flipflopping.

[dmethvin]

Per http://bugs.jquery.com/ticket/10545 we are destroying that flipflopper timmywil's political career.

[ryanflorence]

I agree, this is probably the best decision after further thought. I still think, however, that the AMD stuff should move into the outro so all "exporting" of jQuery is done in the same place.

On Nov 6, 2011, at 2:45 PM, Dave Methvin wrote:

Per http://bugs.jquery.com/ticket/10545 we are destroying that flipflopper timmywil's political career.

---

Reply to this email directly or view it on GitHub:
#557 (comment)

[jrburke]

I still think, however, that the AMD stuff should move into the outro so all "exporting" of jQuery is done in the same place.

@rpflorence, I think it still may move to the outro to help with the issue found as described in this ticket, even if the global is kept.

[SlexAxton]

I didn't know about this ticket, but as someone who uses AMD jQuery in production on lots of third party sites, I'm glad that I'm the one in control of the noConflicting and globals. People add all kinds of crazy stuff to their pages, and I think the group that we should target to do the extra work is the one that likely knows more about what they're doing. So +1 to moving to the outro, but keeping the global (even though I destroy it everytime).

[jrburke]

Now that I think about it a bit more, I'm not sure the noConflict call will work in the AMD case, at least for loaders that immediately call dependencies once define is called (so curl, not requirejs) until the define call happens after the window assignment in outro. I'll work up a patch.

[jrburke]

Pull request for that other ticket is here.

[nfriedly]

I'm having an issue that's related to this. My company makes a widget that includes jQuery and gets put on our customer's pages. We recently switched to using require.js instead of just concatenating all of our script files, and got an angry phonecall from one of our customers shortly after deploying this change that we were breaking their pages:

Basically, what happened is that during the 4 ms between when our jQuery's define() is called and when my main.js's require() is called, our copy of jQuery is the global one and it's "stealing" the customer's jQuery plugins. When our main code calls jQuery.noConflict(true), it's too late and our copy already has their plugin.

Here's a trimmed-down example of the issue: http://nfriedly.com/stuff/jquery-requirejs-noconflict-issue/example.html? (Note that the issue is depends on timing. If it doesn't occur initially, try clicking the 'Reset' link at the bottom.)

I fixed it for my use-case by editing jQuery as seen in http://nfriedly.com/stuff/jquery-requirejs-noconflict-issue/example.html?patched

I'd like to see this changed even if it has to wait for a fairly major release.

[dmethvin]

Per the discussion above, the problem is that if we don't expose window.jQuery then most of the plugins on the face of the planet won't work unless you are willing to modify them to not expect a global jQuery. If you're willing to do that, just modify jQuery as well.

[dslatten]

One of the main selling points of AMD is that it respects the global namespace. Therefore, a common use case is: developers who need a way to reliably load their app/widget (and its dependencies) in an uncontrolled, unpredictable (browser) environment--without impacting that environment's namespace. Yet jQuery's AMD implementation makes this common use case extremely difficult, if not impossible, to achieve.

As @nfriedly pointed out, forcing jQuery into the global namespace of a page that already has jQuery + plugins on it--even if those globals are immediately removed (or rolled back) by jQuery.noConflict(true)--still creates a situation where the native jQuery plugins can erroneously attach to the AMD-loaded jQuery global and break the page. Another major selling point of AMD is that it allows for asynchronous loading. Why then does asynchronously loading jQuery and/or jQuery plugins lead to global namespace collisions?

It sounds like respect for the global namespace and asynchronous loading are, at best, mutually exclusive when working with AMD + jQuery (in the browser). To top it all off, jQuery defines itself as the named module, jquery, thus imposing unnecessary restrictions on jQuery's modularity. I'm starting to wonder if AMD + jQuery has any benefits at all. It's just like regular jQuery...but you have to wait for RequireJS to load first...?

Anyway, I've been working with AMD and jQuery for like...at least 3 weeks now, so I feel perhaps I should leverage that expertise and propose a new solution.

After glancing at jquery/src/exports.js, I notice that the conditions for pulverizing loading the globals are pretty generic:

if ( typeof window === "object" && typeof window.document === "object" ) {
    window.jQuery = window.$ = jQuery;
}

And just before that is the part where jQuery defines itself as AMD-ready:

if ( typeof define === "function" && define.amd ) {
    define( "jquery", [], function () { return jQuery; } );
}

Here's what I propose. We (and by that I mean @jrburke) define a new piece of the define.amd spec that says something like this:

An example of how `define.amd` may be defined for an implementation that does not modify the global namespace:

define.amd = {
    noconflict: true
};

Then change the pulverizing conditions to something like this:

if ( typeof window === "object" && typeof window.document === "object" && !define.amd.noconflict ) {
    window.jQuery = window.$ = jQuery;
}

The idea here being: allow an AMD loader to use the define.amd global to communicate to jQuery that it wishes to "opt out" of window.jQuery = window.$ = jQuery;

[jrburke]

@dslatten: the current structure is a result of the limits of scripts loading (particularly in IE where it does not match up script execution directly followed by a script load event) and the numerous ways in which developers add jQuery to a page. A lot of this will get better when ECMAScript 6 modules come out -- in particular, the ability to create Module Loader instances that can set separate objects for the "global" for each loader.

Here is what could be done today though, for the global setting, as a result of work that has happened since this ticket first opened:

AMD module config could be used to indicate the noConflict behavior. So an AMD-based project could register this config:

require.config({
  config: {
    'jquery': {
      noConflict: true
    }
  }
});

Then, the jQuery exports.js file could look something like this (note the makeGlobal use, comments removed to make the code snippet smaller):

var makeGlobal = true;
if ( typeof module === "object" && module && typeof module.exports === "object" ) {
    module.exports = jQuery;
} else {
    if ( typeof define === "function" && define.amd ) {
        define( "jquery", ["module"], function (module) { 
            if ( module.config && module.config().noConflict ) {
                makeGlobal = false;
            }
            return jQuery; 
        } );
    }
}

if ( makeGlobal && typeof window === "object" && typeof window.document === "object" ) {
    window.jQuery = window.$ = jQuery;
}

If that is something you think might be useful, then I suggest opening a new, targeted ticket about this noConflict approach using module config. Something like "Use AMD module config to avoid setting jQuery global" and keep that ticket focused on just that aspect of AMD/jQuery interaction.

[dslatten]

I definitely think it would be useful. But unless I'm mistaken, your code example assumes that jQuery's module ID will always be jquery, and that conflicts with another change I'd like to see happen: stop assuming that jQuery's module ID will always be jquery.

[jrburke]

The code change mentioned to skip making a global is separate from deciding if jQuery should register as an anonymous module, and is why I suggested breaking it out as a separate, targeted bug, because it can be done regardless of the anon module choice. The module config just needs to match whatever module ID the module ends up with.

Removing the named jquery would provide less benefit than you may initially perceive though and likely will result in more error reports:

Anonymous modules work by being able to tie a script execution to a script tag. This is very difficult to do if a developer just adds jQuery to the page as an HTML script tag manually after an AMD loader is in the page. In that case, the loader can neither reliably ignore that define call nor give it a name, given how browsers execute scripts and how they fire any script onload/readystate events. It will cause some sort of error.

Anon registration is still recommended for most modules, but given how many sites embed jQuery by default and in weird CMS-driven ways, the named 'jquery' avoids those issues.

On the possible benefit of an anonymous jQuery:

• If you use another third party library that needs jQuery as a dependency, that dependency will likely be using 'jquery' as the dependency name. So, jQuery registering as 'jquery' is not an issue once you have one of those libraries in your project: you should be placing jQuery under the 'jquery' modules ID. Projects that use a module ID like 'vendor/jquery-1.9.1' is an AMD anti-pattern.
• If creating a standalone library that embeds jQuery and that library does not need to do dynamic loading for its internal parts, then using a build with almond and wrapping that file in a closure will avoid any issues with conflicts with another jQuery on the page.
• There are things like multiversion contexts and AMD namespace renaming available for standalone libraries that need dynamic loading.

There are definitely use cases that could benefit from jQuery not naming itself. However, the likelihood of errors being caused by manually authored HTML script tags for jquery.js are greater to me, and would lead to more support costs to jQuery and AMD loaders as people would report those errors. If one of those use cases is super important to you, you always have the option to modify your local copy of jquery.js and remove the string yourself.

I do see this as a non-ideal setup, but upgrading the web in the wild is difficult and it is about measuring trade-offs, particularly when relying on uneven script loading capabilities across browsers. The real solution as mentioned before will be ES module loaders, which will not suffer from the "pair anonymous module with ID" limitations that script tags have today.

All that said, I am not a jQuery maintainer, and they could decide differently and be fine with the tradeoffs, go with an anonymous call and point people who report errors to AMD loader sites. I do think they will get reports of issues with that change, but if they are fine with processing those reports with a standard boilerplate of "go talk to your AMD loader of choice for suggestions on how to deal with it", that would be a way to deal with that support cost.

But the choice to create a global via module config vs. switching to an anon call should be tracked and discussed as separate issues.

[dslatten]

This is my understanding so far:

• If an AMD-compatible script (one that initiates a define call if an AMD loader is detected) is loaded (via a <script> tag) after an AMD loader--and the AMD loader didn't specify that script as a dependency (i.e., assign it a module ID)--then errors will occur.
• The workaround is to make sure that AMD-compatible scripts (not native AMD modules) use a named define call. This allows the AMD loader to safely ignore define calls that it didn't initiate.
• The only JavaScript library that is expected to implement this workaround is jQuery. Less-popular libraries should choose between (1) not being AMD-compatible, or (2) not being <script>-compatible on pages that use an AMD loader (unless loaded before it).
• Only the first define call (e.g., for jquery) is accepted by the AMD loader. Subsequent define calls are safely ignored. As a result, AMD modules that depend on jQuery cannot reliably execute in an uncontrolled environment, because there's no guarantee that jquery will return the correct version of jQuery. In fact, there's no guarantee that jquery will return _any_ version of jQuery; it's entirely possible that another script has already defined a module called jquery and mapped it to some arbitrary custom script.

If you use another third party library that needs jQuery as a dependency, that dependency will likely be using 'jquery' as the dependency name.

This is only likely because it's hard-coded into jQuery itself! Otherwise, the most-likely choice would be the filename that jQuery is distributed by (minus the .js extension), because it requires the least amount of effort (e.g., path configuration or renaming files).

So, jQuery registering as 'jquery' is not an issue once you have one of those libraries in your project...

Based on my understanding, it's still an issue in at least 2 cases:

1. Different versions of jQuery are needed within the same page (by different AMD modules that are unaware of the other's existence).
2. Someone customizes a copy of jQuery, but doesn't change the part that defines it as the jquery module.

...you should be placing jQuery under the 'jquery' modules ID. Projects that use a module ID like 'vendor/jquery-1.9.1' is an AMD anti-pattern.

So in an effort to encourage modular/reusable/interoperable code, AMD recommends a best practice that all-but-guarantees namespace collisions and interoperability limitations?

If creating a standalone library that embeds jQuery and that library does not need to do dynamic loading for its internal parts, then using a build with almond and wrapping that file in a closure will avoid any issues with conflicts with another jQuery on the page.

So if I create an app according to the Asynchrous Module Definition specs, and I need my app to asynchronously load JavaScript modules (including jQuery), then my only option is to build a version that isn't modular and doesn't load asynchronously?

I don't know...it seems like the more I learn about AMD, the less it makes sense.

[nfriedly]

Now that jQuery is starting to support custom builds, perhaps both the global definition & the named module parts could be configured at build time?

That way 99% of jQuery users can keep the current behavior, but those of us that need a private jQuery can have a reliable, automated method of getting it.

I don't mind having an extra step in my JS build process as long as it can be automated. What I don't like is the current situation where I have to remember to manually edit a third-party library whenever I upgrade it to a new version. (And I especially don't like cases like this where the mistake won't be immediately apparent, so it's more likely to make it through QA and not get noticed until it starts breaking production websites.)

[dslatten]

@nfriedly +1

[jrburke]

If you use another third party library that needs jQuery as a dependency, that dependency will likely be using 'jquery' as the dependency name.

This is only likely because it's hard-coded into jQuery itself! Otherwise, the most-likely choice would be the filename that jQuery is distributed by (minus the .js extension), because it requires the least amount of effort (e.g., path configuration or renaming files).

For third party libraries that depend on jQuery, they need a name to refer to jQuery. Backbone is a good example. In an AMD version of it, it would depend on 'jquery' and 'underscore'. It uses these top level IDs because it cannot possibly know the path to the file that is used in projects. All jQuery plugins in a modular world would use 'jquery' as the dependency name for similar reasons.

So, jQuery registering as 'jquery' is not an issue once you have one of those libraries in your project...

Based on my understanding, it's still an issue in at least 2 cases:

1. Different versions of jQuery are needed within the same page (by different AMD modules that are unaware of the other's existence).
2. Someone customizes a copy of jQuery, but doesn't change the part that defines it as the jquery module.

For both of those situations, they likely need full module namespace separation. Not just jQuery, but the plugins each one uses. It is unlikely the user would try to also rename all the modules used for the two different versions of jQuery to avoid conflicts. That is what the aforementioned multiversion support and namespace building provides. Complete namespace separation without needing to manually modify the source files.

...you should be placing jQuery under the 'jquery' modules ID. Projects that use a module ID like 'vendor/jquery-1.9.1' is an AMD anti-pattern.

So in an effort to encourage modular/reusable/interoperable code, AMD recommends a best practice that all-but-guarantees namespace collisions and interoperability limitations?

See above about the tools available to contain namespaces. Those are available without needing the actual modules to do anything special. Once IDs are strings, instead of globals, it allows those approaches.

The interop limitations stem from the uneven tech in browsers and a lack of a true module system that can give real, isolated spaces like the ES Module Loader API can.

So if I create an app according to the Asynchrous Module Definition specs, and I need my app to asynchronously load JavaScript modules (including jQuery), then my only option is to build a version that isn't modular and doesn't load asynchronously?

Please see the above multiversion and namespace builds as options for containment. They still allow for async loading.

I don't know...it seems like the more I learn about AMD, the less it makes sense.

Feel free to wait for ES modules. Nothing else today will do better though, and a lot of the same ideas will still be in play with ES modules. ES modules will have a much stronger isolation story though since it has the option to change the language and the browser.

All that said, I think your suggestion about getting some mechanism to avoid setting a global can be addressed, and I think that still may be worth pursuing separately in a targeted ticket.

For build options, I can see allowing options for those things, but for a standard build, I would like to see the module config support for skipping the global and the named jquery as the default options.

[nfriedly]

...for a standard build, I would like to see the module config support for skipping the global and the named jquery as the default options.

I forgot to mention it in my previous comment, but I'd be happy with this as well.

[timmywil]

For build options, I can see allowing options for those things, but for a standard build, I would like to see the module config support for skipping the global and the named jquery as the default options.

This is a great idea.

[timmywil]

I've opened a ticket for this. Please continue discussion there. http://bugs.jquery.com/ticket/14016