(AKA multi-version support or rescoping)
Just develop as if you have full control and ownership over the dojo and dijit on the page. Later, the component can be built into a distributable package that includes its own, private instance of dojo and dijit (see below).
Again, just develop as if you have full control and ownership over the dojo and dijit on the page. But with the AMD API you can set up your dev environment so that you actually have multiple instances of dojo and dijit (or any other module trees) on the page while developing--no build required. Notice the console when you load this example: multiple instances...also the load time is much faster!
The idea is to force the loader into cross-domain mode so that even local, unbuilt resources will be transformed to built, AMD modules on-the-fly. With these transformations, we can have multiple instances of dojo and dijit (or any other module trees) on the page while developing--no build require. Notice the console when you load this example: multiple instance, but it's the slowest of the bunch.
Generally, this mode is not useful under normal circumstances. However, it is a good test of the cross-domain loader in the presense of relocated module trees.
The v1.7 builder converts all legacy modules to AMD modules. This allows any legacy tree to be relocated just as if it was an AMD tree all along. The profile coolio-legacy.profile.js is included to build the coolio project. It anticipates relocating dojo and dijit (the builder needs to know which modules may be relocated when it converts legacy modules to AMD modules; it does not need to know the actual relocated names). You can build the coolio demostration by executing the following command from the util/buildscripts directory
./build.sh profile=../../dojo/tests/_base/loader/coolio/coolio.profile.js
There are four demonstrations of the built code
Remember to do a build before you try these!