Hacker's ramblings

Dojo JavaScript framework has a nice system of packaging the library for your own app. During packaging you may minify the library, reduce the number of files being loaded and leave unnecessary parts out from it. However, ever since Dojo 1.7 the build system is pretty complex and documentation is almost non-existent. There is zero beginner documentation, the existing documentation is aimed towards those, who already know their way around.

The prerequisites for doing a Dojo build is Node.js and Java runtime. The rumour is that build would work with either one of those, but I most definitely cannot confirm that. My production and development boxes have CentOS 6.4, so initially I did not have either one of those installed. To comply with requirements, I installed my own build of Node.js 0.10.4 and for Java OpenJDK 1.7.0 (the package is called java-1.7.0-openjdk in CentOS).

My CentOS 6 RPMs of Node.js are available at http://opensource.hqcodeshop.com/Node.js/ if you need them.

Then to the Dojo-build. There is the IMHO crappy docs at http://dojotoolkit.org/reference-guide/1.8/build/. Most of the stuff I needed to figure out, I had to Google or look from the source. When you unpack the source-package you'll end up having an util/buildscripts/profiles/ directory, which does not exist in the release (minified) package.

A build profile is kind of a makefile. It instructs the build what to package and how. To my great surprise they changed the profile style and you'll find two different styles:

1. Old style:
   • dependencies = { / A JavaScript object definition here / }
2. New Style:
   • var profile = (function(){ / A JavaScript object definition here / });

A standard Dojo release build is done with profile named standard (no surprises there, huh?). The command for doing that would be, for example:

./util/buildscripts/build.sh profile=standard version=1.3.2-dev \
 releaseName=dojo-release-1.3.2-dev cssOptimize=comments.keepLines \
 optimize=shrinksafe.keepLines cssImportIgnore=../dijit.css action=release

I tried to emulate that with a new-style profile file of my own. The profile-file has most of the command-line parameter in it, so running it will be much simpler, copy the profile into profiles-directory and something like this will do:

./util/buildscripts/build.sh profile=Dojo-JaTu cssOptimize=comments.keepLines \
 cssImportIgnore=../dijit.css action=release

There are number of choices you may do with the profile, for example you may choose not to minimize it, by changing following:

mini: false,
optimize: false,
layerOptimize: false,

This produces a built, but debuggable file which is much nearer to release than the source-package. You see, the build will replace number of options with structures like
if (1) { / then something / }, which initially look strange, but in reality just reflect the hard-coded changes you made during build. The release version will have those anyway, no matter which release version you'll use. Doing your own custom build, you'll have a control over which parts of the code are in and which are out.

I still haven't grasped the "layer"-concept fully. A layer is a single file containing a number of Dojo-modules. Anyway, that definitely is something worth studying. It will yield much faster loading web pages.

Trying to wrangle Dojo and struggling with its build system took me a nice working week. That was time well spent. Now I can make my own tailored Dojo-packages for a production site which loads really fast.