After all the difficulty trying to test Require.js AMD modules with Jasmine I ended up switching over to load.js, a barebones little script loader that basically makes it possible to formalize dependencies as an ordered chain of functions. Now, the entire load order is defined in a single file,
loader.js, that sits above the application in the file structure:
From a theoretical/structural standpoint this is clearly somewhat less sophisticated since the component files don’t map out dependencies as standalone units, meaning that they work on magic constructs that aren’t locally defined (for example, the top-level
Ov object domain, and
Backbone). It also means that the loader file has to be manually curated as files are added, renamed, or removed from the file system. This is annoying, and a source of errors – I frittered away about ten minutes last night trying to figure out why I couldn’t access some methods added by a Backbone add-on module, only to realize that I had dropped the file into the vendor directory but neglected to add it in to the load sequence.
At the same time, this approach has major benefits. Jasmine can vacuum up the files directly into the test runner, and the components can be manipulated directly without having to do bizarre contortions to trick the test suite into indulging AMD. And part of me kind of likes having a single file that defines the entire load process in a single place. I can imagine that this would get less fun in a really large application with many dozens of files, but for the time being it’s nice to be able to quickly scan the whole dependency stack in one file.