I’d like to add that anyone planning to release a Mootools plugin or a codebase that sits on top of Mootools (like Clientcide) should really make sure to have a well-formed scripts.json file that maps all of the internal and external (to mootools) dependencies. One good way to make sure this works is to test your code using Aaron’s Mootools Unit Test Framework, as it needs a good scripts.json file to function.

Having your dependencies mapped will make it much easier for other developers to use your code, especially if they’re generating JS lib files dynamically (as in Mooish).

Since I wrote JazzRecord (www.jazzrecord.org) and released it, I’ve had a few folks correspond with me. I’m getting free testing and opinions. They’ve helped me find problems I probably wouldn’t have found on my own for some time. I wrote this lib for fun and as a challenge, and to know its of use to someone else is really the biggest treat.

Just as background: JazzRecord is a JavaScript port of Ruby on Rails’ implementation of ActiveRecord ORM that allows you to work easily with sqlite databases in Gears, AIR and Titanium currently.

Writing automated tests (I’ve been using JSSpec) is hugely helpful. Though I need to expand my tests to cover new issues we’ve recently uncovered, (and new features being added) I’ve caught several mistakes I’ve made when fixing other bugs thanks to automated testing. Prior to my current job I hadn’t written tests regularly, and re-wiring my brain for that also helped a lot. Nice, readable syntax in JSSpec and the mentality of BDD vs testing detailed internals also helps.

After first coding a project, especially something as large as JazzRecord, keeping documentation up-to-date is probably the biggest challenge. It’s also the easiest thing to postpone, but having good documentation is another extremely important part of releasing a largish project.

JazzRecord is currently a MooTools project, but will soon be made independent from any other library.