Bug Tracker

Ticket #14016 (closed feature: fixed)

Opened 22 months ago

Last modified 15 months ago

Include a build option for customizing exports

Reported by: timmywil Owned by: timmywil
Priority: high Milestone: 1.11/2.1
Component: build Version: 1.10.1
Keywords: Cc:
Blocking: Blocked by:


Discussion here:  https://github.com/jquery/jquery/pull/557

There are some who would like the ability to customize the way jQuery is exported. This could easily be done with a build option without affecting the way 90-something% of users need jQuery to be exported.

Change History

comment:1 Changed 22 months ago by timmywil

  • Priority changed from undecided to high
  • Status changed from new to open
  • Component changed from unfiled to build
  • Milestone changed from None to 1.10.2/2.0.3

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.

comment:2 Changed 22 months ago by nfriedly

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; } );


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

comment:3 Changed 22 months ago by timmywil

  • Type changed from bug to feature

comment:4 Changed 22 months ago by timmywil

  • Owner set to timmywil
  • Status changed from open to assigned

comment:5 follow-up: ↓ 6 Changed 22 months ago by 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:


comment:6 in reply to: ↑ 5 Changed 22 months ago by jaubourg

Replying to 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:


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?

comment:7 Changed 21 months ago by jrburke

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.

comment:8 Changed 21 months ago by timmywil


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

comment:9 Changed 20 months ago by timmywil

  • Milestone changed from 1.10.2/2.0.3 to 1.11/2.1

comment:10 Changed 16 months ago by timmywil

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')

comment:11 Changed 15 months ago by Timmy Willison

Build: Add the ability to remove global exposure.

Ref #14016

Changeset: a6f474e699f95a90f95228bd525490151acc0451

comment:12 Changed 15 months ago by Timmy Willison

  • Status changed from assigned to closed
  • Resolution set to fixed

Build: add build option for setting the AMD name.

Fixes #14016.

Changeset: 7e8a91c205723f11cd00c8834f348a649ab15926

Note: See TracTickets for help on using tickets.