A dependency manager for web projects

The problem

Effective, modular development usually comes with a dependency management tool. Think easy_install for python, ruby gems for ruby, npm for Node.

Front-end web development does not have this kind of tool. Traditionally it has been ad-hoc script management done by the developer. However, now that modular development is available now, and will become more prevalent as ECMAScript committee solidifies native module support, front end developers should have a dependency management tool.

volo, a solution

volo is a concrete attempt at this solution. While I do not believe it is fully formed yet, it is already useful, and by having something real to start from, it will better inform any coordinated effort.

volo does not have to be the only dependency management tool. Hopefully we can use it as way to discuss common approaches that we can all share.

There have been some efforts in this space, in particular npm, cpm and bpm. I go into why those were not used for volo in a Prior art page.

The main point of departure is the choice of registry. volo uses GitHub.

GitHub as the registry

One of the difficulties with running a dependency management tool is having an effective way to find dependencies. The JavaScript community has really embraced GitHub, and I think it has all of the right pieces to serve as a registry:

• Allows forks. Namespacing is possible via the use of the owner's name, not just a project name.
• Has a search function that can give owner/repo values for a given dependency name.
• Encourages open source and social communities around the source. 
• Supports tags for versions.
• GitHub has a great simple API for getting versions/repo info.
• Provides zipballs/tarballs of tags/branches.
• Dependencies can be pulled not only by version tag but by branch name.
• Provides a Downloads area for built code.

Most importantly, it means volo is already useful without having to stand up a registry or require developers to push code to new places. Many projects can be fetched as-is, and some just need a package.json property to be usable.

Conventions

volo uses some conventions that are used by some JS projects already, to make it easier to bootstrap. For other projects, usually one package.json property is enough for it to be used by volo.

Check out the Library best practices document for the conventions and configuration used by volo. volo has some project-specific overrides it uses during this bootstrap phase, to simulate how those projects would behave if they used the package.json property that mapped to their development style.

Try it Out

So try it out. It is just one JS file that runs in Node, so it is easy to get rid of it if you do not like it.

volo's 0.1.0 release has search built in, so it is fun just to try the following kinds of commands to see what it finds on GitHub:

    > volo search jquery

    > volo search backbone

    > volo add jquery

    > volo add dojo

    > volo add dijit

    > volo add ember

Next Steps

While volo is useful already, it is certainly not done. In particular,

• Do the library best practices make sense? Also, there is info the rules "volo add" uses. I am hopeful volo allows for a reasonable default convention but still give enough flexibility via a couple package.json properties, including a way to embed a /*package.json*/ comment for single file JS libraries.
• volo does not install nested dependencies yet. It is doable, just needs a bit more coding.
• A private/local server that responds to the GitHub APIs used by volo would be useful. Not all code can be placed on GitHub or a public URL, and sometimes even for a developer, having a local cache server is useful. I'm hoping this server can proxy to GitHub for common public libraries and cache them, and then provide a mechanism for private libraries to live in that server.
• volo does not support .tar.gz files yet, but it might be nice if it did. zip files were just easier to get working cross-platform.
• Allow access to private GitHub repos by using OAuth with GitHub.
• Allow a "volo.versions" section in a package.json, to allow listing versions without having to use GitHub tags. This could be useful for libraries that do not want to host their code in GitHub.

I would like to discuss these topics with other interested parties. In the absence of a common list for it, I suggest using the volo list, but I am more than happy to have the discussion take place in a new common space. As mentioned above -- volo does not have to be the only tool in this space, but it would be great to work out common conventions and configuration that would allow interop.
If you have a specific code issue, feel free to open a volo issue.