The loader extension config

The loader extension config is specified on the client using the combo property of the require AMD loader config as illustrated in the following example.

require = {
    paths: {
        // define module paths
    },
    packages: {
        // define module packages
    },
    combo: {
        contextPath: "testaggr",
        expandRequire: true,
        extraArgs: {
            foo: "bar"
        }
    }
};

The AMD loader config, along with the loader extension config (the combo property), must be specified before the Aggregator provided loader extension JavaScript and the AMD loader are loaded. A number of config properties are honored only when the Aggregator is running in development mode. These are identified in the table below. See Options for information on how to run the Aggregator in development mode. The loader extension config may specify the following properties:

</tbody>

Property	Description
contextPath	The URL path of the Aggregator service. This is typically the value of the alias attribute in the <servelt> element defining the Aggregator servlet) in plugin.xml, but it may also be a page relative URL. This property is required.
expandRequire	If boolean true or "true" or "1", then the Aggregator will perform require list expansion. If the value of this property is the string "log", then the Aggregator will perform require list expansion with logging to the browser console (using console.log()) of detailed information about the expansion. This information is useful in analyzing why a particular module is included, or not included, in an expanded require list. This property maps directly to the expandRequire URL query arg for the Aggregator servlet. If development mode or debug mode is not enabled, then specifying 'log' has the same effect as specifying 'true'. Note that this property and serverExpandedLayers are mutually exclusive. If both are specified, then serverExpandLayers will have precedence.
serverExpandLayers	If boolean true or "true" or "1", then the Aggregator will perform server-side layer expansion. Note that this property and expandRequire are mutually exclusive. If both are specified, then this property will have precedence, but you can still specify `expandRequire=log` to enable dependency expansion logging. This property is new in version 1.2.2.
optimize	One of "simple", "whitespace" or "none". Specifies the level of optimization performed on the requested modules. The default value is "simple". This property maps directly to the optimize URL query arg for the Aggregator servlet. Development mode or debug mode must be enabled for this option to be recognized. With versions of the Aggregator prior to 1.2, setting the value of this property to "none" has the side-effect of disabling module name exporting (see the exportNames property in this table) because the module name exporting of JavaScript modules is performed by a custom compiler pass module using the Google closure compiler and when optimization is disabled, then the compiler is not used. With version 1.2 and above, there are no limitations associated with using optimize=none.
cacheBust	An arbitrary string specified by the application that will be included as the value of the 'cb' query argument in all Aggregator requests. This property maps directly to the cb URL query arg for the Aggregator servlet.
exportNames (Pre-1.2 only)	If boolean true or "true" or "1", then the Aggregator will export module names in the define() functions of anonymous modules. In general, AMD modules should be anonymous to make them portable, but some loaders may require that module names be provided in Aggregated builds, and module names must be provided for modules that are loaded using the same request that loads the loader. Anonymous modules do not declare the module name in the define() function. For example, the following defines an anonymous module: define([ "dojo/connect", "dojo/query" ], function(connect, query) { . . . }); When a module is requested and this option is specified, the name used to request the module is inserted into the define function as the first parameter, so if the module containing the example above is requested as js/moduleA, then the define function will be rewritten by the Aggregator as follows: define("js/moduleA", [ "dojo/connect", "dojo/query" ], function(connect, query) { . . . }); This option does not work when optimze='none' is specified because the functionality is implemented by a custom compiler pass and the compiler is not used when optimization is disabled. This option maps directly to the exportName URL query arg for the Aggregator servlet. This option is only available on versions of the Aggregator prior to 1.2. In 1.2, and above, module names are always exported and there is no restriction with regard to module name exporting and optimization level.
extraArgs	Aggregator extensions may support additional query args in Aggregator URLs.  This property provides a mechanism for applications to specify name/value pairs for arbitrary query args. The value is an object who's property names and values are mapped directly to URL query arg names and values for all Aggregator requests.
featureFilter	Optionally specifies a JavaScript function that accepts feature name and returns true if the feature name and value should be sent to the server or false if it should be filtered out.
showFilenames	If boolean true or "true" or "1", then a line-feed plus a javascript comment string containing the name and location of the resource on the server will be included before the contents of each aggregated module in the response. The default value is false. This option maps directly to the showFilenames URL query arg for the Aggregator servlet. Development mode or debug mode must be enabled for this option to be recognized. </td> </tr> <tr> <td> <strong>noCache</strong></td> <td> If boolean true or "true" or "1", then the aggregator will ignore cache files on the server and always build the response from scratch, and Aggregator responses will contain the "Cache-Control:no-store" header to prevent the response from being cached by the browser or third-party caches. Useful when developing/debugging module builders or trying to verify that an issue is not cache related. This option maps directly to the <strong>noCache</strong> URL query arg for the Aggregator servlet. This option has no effect if development or debug mode is not enabled. Note: this options does not bypass the use of the cached dependency map used in require list expansion. </td> </tr> <tr> <td> <strong>hasBranching</strong></td> <td> If boolean true or "true" or "1", then the aggregator will perform <a href="./Require-list-expansion#has-plugin-branching-in-require-list-expansion">has! loader plugin branching in require list expansion</a>. The default value for this config property is true, so it doesn't need to be specified unless you want to disable the feature. </td> </tr> <tr> <td> <strong>i18nSplit</strong></td> <td><a name="i18nsplit"></a> If true, then loader generated requests will be split into requests for i18n resources and non-i18n resources. Requesting i18n resources separately can improve the effectiveness of public caches by enabling greater cache reuse of non-language-specific responses. If your application supports many languages, you may want to use this feature. Note that this option only affects loader generated requests. To omit i18n resources from application generated requests for bootstrap layers, simply don't include the name of the i18n loader plugin in the jsPluginDelegators Server-side AMD config property.