There is still some debate as to what the default options should be. I'm still inclined to say that we need to keep the exposed global when defining with AMD, but some feel differently.

This ticket covers two changes to exports.js that are somewhat related:

1) Option to never create global jQuery and $ variables. Basically remove this code:

// If there is a window object, that at least has a document property,
// define jQuery and $ identifiers
if ( typeof window === "object" && typeof window.document === "object" ) {
    window.jQuery = window.$ = jQuery;
}

2) Option to change named define() call to an anonymous define call. This would change

define( "jquery", [], function () { return jQuery; } );

to

define( [], function () { return jQuery; } );

I believe the current output for a jquery build should still be the default, and seems fine to provide for both of the options above.

Although, the "do not create a global" path could also be handled via module config as shown in this comment:

https://github.com/jquery/jquery/pull/557#issuecomment-19143292

Replying to [comment:5 jrburke]:

I believe the current output for a jquery build should still be the default, and seems fine to provide for both of the options above. Although, the "do not create a global" path could also be handled via module config as shown in this comment: https://github.com/jquery/jquery/pull/557#issuecomment-19143292

Not directly related to the ticket but wanted to make some precisions...

The problem is how convoluted those sniffings are in the end. The idea we're exploring right now is to generate the main jQuery closure internally then use it as a base to build the node module and the browser version from there.

The node module will be installed using npm anyway, so having a different file than the browser version cannot cause confusion. It also allows us to publish the node module as a function that depends on the window object :

var window = require( "whateverBrowserEmulator" ).factory();
var jquery = require( "jquery" )( window );

So we don't have to sniff for module, we don't need a global window. If someone wants to use amd in node, it's only a matter of creating a jquery-amd npm module that uses the official jquery module and does the plumbing.

As for the matter at hand (name of the export in the browser version), it's more a matter of determining proper build options than anything else :

• export/no export
• name of the export
• global/no global

Unless I'm missing something big?

Sorry, I thought commenting would automatically add me to watch the ticket, but I messed up. Watching it now. To jaubourg's comment:

I generally prefer a .js file for a library that is the same for any environment. Some people do not just use npm for node code for example, some want to use it for front end code. In other words, the publish point is not the same as the runtime environment. For me as a library author, I do not want my first support question back to them being "where did you get my library from", and prefer to just know the version.

But I imagine the jQuery folks have had a few discussions on that matter, and maybe it is moot given that custom builds of jQuery are possible now.

As for allowing a custom setting for window -- I do not imagine other libraries, like jQuery plugins will do that. If there is some emulation environment, I expect it should have worked out a good enough browser environment to run browser-targeted code as-is, as a front end project normally has lots of other browser-specific code in it. But, a side topic to this ticket.

As to this ticket, for custom builds: for AMD uses, I think the choices that are desired are:

• Should jQuery create its globals
• The name to use for the AMD registration. Default 'jquery', if left blank, then no named define() call, just define(function(){}). If set to some other value, then a named registration for that value.

I believe that is basically the same as to what jaubourg listed.

@jrburke

Although, the "do not create a global" path could also be handled via module config

I think this is a great idea. I've created another ticket to add that to both 1.x and 2.x branches:

http://bugs.jquery.com/ticket/14076

To sum up our intentions, we'll be adding 2 build options:

1. Remove global definitions. We won't use AMD config for this because CommonJS folks want this too.

2. The name for AMD registration (defaults to 'jquery')

Build: Add the ability to remove global exposure.

Ref #14016

Changeset: a6f474e699f95a90f95228bd525490151acc0451

Build: add build option for setting the AMD name.

Fixes #14016.

Changeset: 7e8a91c205723f11cd00c8834f348a649ab15926