Dojo 1.9 build 'multipleDefine' error loading locale

Question

The dojo My dojo application crashes after assembly during application loading, throwing 'multipleDefine' and throwing this error:

Error {src: "dojoLoader", information: object}

Message: multipleDefine

info: Object {pid: "dojo", mid: "dojo / nls / dojo_en-us", pack: Object, url: "dojo / nls / dojo_en-us.js, executed: 5 ...}

Here is my profile:

var profile = { // `basePath` is relative to the directory containing this profile file; in this case, it is being set to the // src/ directory, which is the same place as the `baseUrl` directory in the loader configuration. (If you change // this, you will also need to update run.js.) basePath: '../src/', // This is the directory within the release directory where built packages will be placed. The release directory // itself is defined by `build.sh`. You should probably not use this; it is a legacy option dating back to Dojo // 0.4. // If you do use this, you will need to update build.sh, too. // releaseName: '', // Builds a new release. action: 'release', // Strips all comments and whitespace from CSS files and inlines @imports where possible. //cssOptimize: 'comments', // Excludes tests, demos, and original template files from being included in the built version. mini: true, // Uses Closure Compiler as the JavaScript minifier. This can also be set to "shrinksafe" to use ShrinkSafe, // though ShrinkSafe is deprecated and not recommended. // This option defaults to "" (no compression) if not provided. optimize: '', // We're building layers, so we need to set the minifier to use for those, too. // This defaults to "shrinksafe" if not provided. //layerOptimize: 'closure', layerOptimize: '', // Strips all calls to console functions within the code. You can also set this to "warn" to strip everything // but console.error, and any other truthy value to strip everything but console.warn and console.error. // This defaults to "normal" (strip all but warn and error) if not provided. stripConsole: 'all', // The default selector engine is not included by default in a dojo.js build in order to make mobile builds // smaller. We add it back here to avoid that extra HTTP request. There is also a "lite" selector available; if // you use that, you will need to set the `selectorEngine` property in `app/run.js`, too. (The "lite" engine is // only suitable if you are not supporting IE7 and earlier.) selectorEngine: 'acme', //localeList:"en-gb,en-us,de-de,es-es,fr-fr,it-it,pt-br,ko-kr,zh-tw,zh-cn,ja-jp", // Builds can be split into multiple different JavaScript files called "layers". This allows applications to // defer loading large sections of code until they are actually required while still allowing multiple modules to // be compiled into a single file. layers: { // This is the main loader module. It is a little special because it is treated like an AMD module even though // it is actually just plain JavaScript. There is some extra magic in the build system specifically for this // module ID. 'dojo/dojo': { // In addition to the loader `dojo/dojo` and the loader configuration file `app/run`, we are also including // the main application `app/main` and the `dojo/i18n` and `dojo/domReady` modules because, while they are // all conditional dependencies in `app/main`, we do not want to have to make extra HTTP requests for such // tiny files. include: [ 'dojo/i18n', 'dojo/domReady', 'app/main', 'app/run' ], // By default, the build system will try to include `dojo/main` in the built `dojo/dojo` layer, which adds // a bunch of stuff we do not want or need. We want the initial script load to be as small and quick to // load as possible, so we configure it as a custom, bootable base. boot: true, customBase: true }, }, // Providing hints to the build system allows code to be conditionally removed on a more granular level than // simple module dependencies can allow. This is especially useful for creating tiny mobile builds. // Keep in mind that dead code removal only happens in minifiers that support it! Currently, only Closure Compiler // to the Dojo build system with dead code removal. // A documented list of has-flags in use within the toolkit can be found at // <http://dojotoolkit.org/reference-guide/dojo/has.html>. staticHasFeatures: { // The trace & log APIs are used for debugging the loader, so we do not need them in the build. 'dojo-trace-api': 0, 'dojo-log-api': 0, // This causes normally private loader data to be exposed for debugging. In a release build, we do not need // that either. 'dojo-publish-privates': 0, // This application is pure AMD, so get rid of the legacy loader. 'dojo-sync-loader': 0, // `dojo-xhr-factory` relies on `dojo-sync-loader`, which we have removed. 'dojo-xhr-factory': 0, // We are not loading tests in production, so we can get rid of some test sniffing code. 'dojo-test-sniff': 0 } 

}

and here is index.html inside src /

NOTE. build.sh is responsible for removing the "isDebug" flag when deploying to production. If you change this flag at all, you will break the assembly!

 <script data-dojo-config="async: 1, tlmSiblingOfDojo: 0, locale:'en_US', isDebug: 1" src="dojo/dojo.js"></script> <!-- Load the loader configuration script. Note that this module ID is hard-coded in build.sh in order to provide an optimised build that loads as few as one script for the entire application. If you change the name or location of this module, you will need to update build.sh too. --> <script src="app/run.js"></script> 

this is the generated index.html in dist /

 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <link rel="stylesheet" href="app/resources/app.css"> </head> <body class="claro"> <script data-dojo-config= "async: 1, tlmSiblingOfDojo: 0, locale:'en_US', deps:['app/run']" src="dojo/dojo.js"></script> </body> </html> 

I checked that dojo / nls / dojo_en-us.js exists and that is normal. I am stuck at this point, having no idea!

Any help in solving this problem is welcome.

Answer 1

Can you post your requests in run.js? Do you need dojo / _ base / config?

[just noticed the same mistake because I forgot it;)]

from documents:

It is important to note the difference between dojoConfig and dojo / _ base / config. dojoConfig is intended solely for input - this is how we pass configuration parameters to the loader and modules. During the boot process, dojo / _ base / config is populated from these parameters for subsequent module search.

Answer 2

I had a similar error issue

multipleDefine

while trying to include the greensock library in my dojo project.

The problem occurs when another library outside of dojo announces its own define function (in my case TweenMax), as they encounter the dojo loader.

The solution is to make sure the dojo loader is called after your library or script that use the define function has loaded.

So dojo should be the last in your script to load in the html head :

 <head> <script src="yourLibrary.js"></script> <script src="dojo/dojo.js"></script> </head> 

This issue is also visible with jQuery UI and other libraries.

Answer 3

There is a note about this in the bootloader documentation (during this answer anyway).

multipleDefine
AMD define is called a reference to a module that has already been defined. The most common cause of this problem is loading modules through elements in an HTML document. Use the bootloader; do not use items. The second most common reason is the explicit identifiers of the modules to define; don't do this either.

https://dojotoolkit.org/reference-guide/1.10/loader/amd.html

Currently, many libraries are implementing UMD, which will mainly try to automatically detect the presence of an AMD bootloader. For example, Bootstrap, the popular front-end framework, implements UMD.

So, the following example will work (note that the bootloader will boot globally):

 <script src="path/to/bootstrap.js"></script><!--UMD packaged library--> <script src="path/to/dojo/dojo.js"></script><!--then dojo loader--> 

but the second example below will not work as the UMD code is detected by the AMD bootloader and uses it to register. This will result in a multipleDefine error as per the documentation.

 <script src="path/to/dojo/dojo.js"></script><!--dojo loader first--> <script src="path/to/bootstrap.js"></script><!--then UMD library--> 

If you want to download the library globally, use the first example above and load it before the dojo loader. If you want to load the library as an AMD module, use the bootloader.