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.
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.
If you have a specific code issue, feel free to open a volo issue.
No comments:
Post a Comment