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. Note: properties that take a boolean value will recognize any of true, 1, "true" or "1" as being true.

<\tr>

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 true, 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 serverExpandLayers are mutually exclusive. If both are specified, then serverExpandLayers will have precedence.
serverExpandLayers	If true, 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 URL query argument in all Aggregator requests. Note that the cb query arg is not recognized by the aggregator. The argument is provide simply for the purpose of busting the cache.
exportNames (Pre-1.2 only)	If true, 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 optimize=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 exportNames 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 a 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. Filtered features will be undefined on the server when processing requests. Code trimming using has.js feature detection will not take place for undefined features, and undefined features in has! loader plugin expressions will result in has! loader plugin branching when using require list expansion or incomplete dependency expansion when using server-side layer expansion. This property can be useful for weeding out those features that don't significantly impact code size or dependency expansion, thereby reducing the possible number of request permutations and increasing cache-hit ratios.
showFilenames	If true, 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><a name="nocache"></a> If true, 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 <a href="Servlet-Query-Args#user-content-nocache"><code>noCache</code></a> 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><a name="hasbranching"></a> If true, 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. This property maps directly to the <a href="Servlet-Query-Args#user-content-hasbranching"><code>hasBranching</code></a> URL query arg. </td> </tr> <tr> <td> <strong>i18nSplit</strong></td> <td><a name="i18nsplit"></a> <p>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 when require list expansion is enabled. It is not supported when using server-side layer expansion, or for application generated bootstrap layers. If you are using this feature and wish to have i18n resources omitted from the application generated bootstrap layer, then you can omit the name of the i18n loader plugin in the jsPluginDelegators server-side AMD config property. Alternatively, you can define your bootstrap layer to not depend on any i18n resources and use the assertNoNLS URL query arg to help keep NLS dependencies from creeping back into the bootstrap layer during development. This property was introduced in version 1.2.2
isSupportedModule	A function that takes a single, module id, parameter and returns true if the specified module id can be loaded by the Aggregator. The default implementation returns false for absolute and server relative URLs and true for all other inputs. If you wish to bypass the Aggregator for certain modules, provide an implementation of this function that returns false for those modules ids and the loader will load those modules individually as if the Aggregator was not in use.
sourcemaps	If true, then source maps will be generated for minified JavaScript code and will be made available to browser clients that support source maps. The sourceMaps option must be enabled for this property to be recognized. This feature is new in version 1.3.3 This property maps directly to the sourcemaps URL query arg for the Aggregator servlet.