The actual process of developing MooTools itself isn’t trivial. It’s not rocket science, but maybe there is a little alchemy involved. For instance, let’s say you want to fix a bug in MooTools More. You fork the library and make the change to fix the bug and now you want to test it. You need MooTools Core for this, but which version? Looking at MooTools Core on Github you see there’s a branch called 1.2x and also a branch called master, not to mention a tag for 1.2.5. MooTools More has several branches, too; there’s master, develop, 1.3wip and others. Which combination of these two libraries work together?
Then you see some test files in the library. Some HTML files that appear to be demos, but they don’t run on their own. You need to install the MooTools Test Runner to view them (you can see an example of it running at review.mootools.net:9876). And then there’s an external specs runner.
If you decide you want to play with MooTools ART you have similar issues, not to mention the widget library – art-widgets – built on top of it.
While it’s true that jsFiddle gives you a sandbox with a lot of these things, it doesn’t give you a working development environment. In an effort to make it easier to share these configurations, I’ve created a portable development environment that makes it relatively easy to get things up and running.
http://github.com/anutron/mootools-development
I’ve made a github repo that has essentially no code and only submodules pointing to all the stuff I use in states that work. In theory, it should make it really easy to reproduce a development environment from scratch. Eventually I’ll configure several different environments. 1.3, 1.2, 1.1, 2.0, whatever.
Right now there are three environments configured. 1.2.5-art-widgets (which includes everything you need to play with art-widgets), 1.3-art-widgets which lets you do the same against MooTools 1.3 (there are some issues that we’re working on so it doesn’t look great at the moment), and 1.2x-tracking-core-more, which includes just mootools-core and mootools-more on their respective 1.2x branches. These are my personal environments and you can use them if you like.
Note that instead of submodules I’m using crepo. One of the reasons is it will allow us to create a version that’s tracking against a branch. For example, the 1.2x-tracking-core-more branch is always tracked against core/master and more/develop. Typing “./go sync” will update to the latest of these two branches.
The result of this means that we can create specific, deployable environments for others and for each other. I could file a lighthouse ticket against -core with a specific state that illustrates a bug in core/1.3 that manifests itself only in art.widgets (which I’ve done – art.sheet is broken in 1.3).
Note that you don’t have to use django to use the environment. My environment includes the test runner that I wrote and depender. But you can just do ./go sync and get all the repos without building the django app.
This doesn’t have to be specific to MooTools, but that’s what I made it for. I don’t see people trying to incorporate this into other tools, though crepo is designed for that purpose (we us it throughout cloudera).