Mozilla WebDev Libraries

Nothing earth-shattering here… but I wanted to capture some ideas that the webdev team has discussed in terms of how we share our code between projects and with the community at large.

Of course 100% of our code is open source, but we want to do a better job of letting others use and contribute to our libraries.

Screenshot of a typical project layout

A typical project

Let’s talk about a theoretical new project foomo which is the code behind Foo.mozilla.org. This project may reuse a couple libraries as well as host it’s own code. Let’s assume this is a project has the layout pictured to the left:

In bin we have various Python and shell scripts which are executed via cron or CLI. These scripts depend on the config directory for configuration and the lib for libraries of code. I won’t focus on the bin part of the project, but it could follow the pattern below, but using a Pythonic packaging idiom.

Let’s assume that the web directory houses a Kohana PHP project. Under the web/application directory there are typical these project specific directories: config, controllers, helpers, hooks, libraries, models, andviews.

In addition to application, Kohana also provides modules and system directories. Let say that foomo project reuses a Mozilla WebDev PHP library barlib library it will be located under modules. system is where Kohana stores it’s framework code that is overridden by modules and application code. But how do we manage foomo and barlib codebases?

Version Control

The authoritative code repositories for this website would be in atleast two places.
If we keep all the code for foomo under one project, say svn.mozilla.org/project/foomo, this makes it easy to deploy and manage. The mainline of application specific code would be changed from here.
The second codebase is for the library barlib. The mainline of development would happen on github.com/projects/barlib. Let’s look at the source code layout of foomo and barlib to see how they relate.

foomo's module directory contains barlib

barlib's project layout

So foomo’s web/modules/barlib on the left is a subset of barlib’s development tree on the right. A read only copy of this dist directory, heck even just a tarball distribution of it, comes from github and lands in foomo’s web/modules/barlib. As we want to enhace barlib, we work in that codebase on the right. barlib is it’s own project, so development includes running it’s tests, etc and then creating a release version to be imported back into foomo, on the left, as needed.

Keeping the official repository for reusable libraries separate introduces some disadvantages, but is worth it.
Disadvantages:

• More complexity and administrative overhead
• Requires more discipline
• You have to manage dependencies between libraries and apps
• Increases development costs

Advantages:

• Encourages Reuse
• Removes barriers for community contribution
• Makes QAing and releasing components possible

All Growed Up

As code in foomo solidifies or another project wants to use chunks outside of just foomo, the various pieces of code can be pulled out into a module and moved from web/application to web/modules/<library name>. We’ll have to re-QA foomo after this code extraction, but we will gain the benefit of reduced development on the second project and anyone who needs it won’t have to pick through foomo internals to copy and paste the tasty chunks. If the second project is a CakePHP project, then all it will need to do is write CakePHP wrappers analogous to the very this Kohana specific layer of barlib.

Everything Cannot Be Reused

Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges. That said, we should spend the extra time it takes to publish and integrate dynamite WebDev libraries.