Require.js difficulties

Frustrating day yesterday trying to get Require.js to play nice with Jasmine. As far as I can tell, this is essentially impossible without resorting to unacceptably aggressive hacks at various levels of the stack (this post by Chris Stom, which, as far as I can tell, is the only actually functional solution, involves directly clobbering parts of the Rack server that spins up the testing suite). Pretty bad.

The problem, essentially, is that the Jasmine gem is designed to load all of the application source files directly into the test environment. This goes against the basic philosophy of Require.js, though, in which all dependencies are only ever loaded by way of the define() calls that wrap all of the application modules. Even if you can hack a special Require.js-compliant “runner” file for the test suite that manages to pull in the source files, the application modules themselves are locally scoped inside of their respective define() wrappers, and thus unavailable to the global namespace where the actual testing takes place. Stom gets around this by manually globalizing all of the application assets when they get loaded in (eg, window.PoemView = PoemView;). Again, though, this doesn’t feel tenable.

Thus far I’ve been following Addy Osmani’s Backbone dependency boilerplate almost verbatim. In the application proper, I really like Require.js – it eliminates big stacks of script includes in server templates, and the separate-file templating by way of the text.js plugin really make it feel like you’re writing a first-class application in the browser (usually, it feels kind of like building a ship in a bottle). Unfortunately, the testing problems are a deal breaker – I’m really determined this time around to make the front-end suite as robust as the server suite, and I don’t want to spend dozens of hours over the course of the next couple months wading through (no doubt ongoing) configuration chaos.

Tonight or tomorrow I’m going to strip out all of the Require.js code and try to drop in one of the more straightforward, lightweight Javascript loaders (this article is a good tour of the many options). The load.js syntax caught my eye; the tiny filesize is nice too. Also, since I can no longer use the text.js template file loading, I’ll need to do the Javascript partial templating in jade, and I’ll need to rig up an automated fixture-generator workflow like I did for Neatline.

I find that setting up testing workflows is always more difficult than I expect. I guess that kind of makes sense, in a way – you’re essentially trying to “use” the application in a way that it’s not really designed to be used.