Consider making volo a plain npm-installable node package

[jrburke]

In the process of figuring out how to do the following:

• allow dependencies for commands in a volofile
• allow use of project-local npm-installed modules
• allow installing reusable components for volo in the current project (project-local)

It seems like it will be better to go with the grain of node instead of some of the custom packaging that volo uses for itself and the use AMD modules for volofiles.

The main goals of volo for me are:

• Promote the use of github for project templates and installing front end dependencies. Front end devs are likely already using github in some fashion, and github, with its tags, branches, downloads area, and built in social features for reporting back issues/interacting with library developers is a better fit than using npm for these tasks, particularly given the nodeisms built into npm.
• Allow other node-based software to reuse the github awareness that volo has for doing searches, resolving github identifiers (owner/repo -> owner/repo/latestVersionTag), and generating URLs to version archives.
• Allow using node to create simple makefile-type of scripts for running project tasks: volofiles. This means the onCreate and onAdd hooks too.

These goals are still achievable with structuring volo as plain npm-installable package. I like being able to have a simple, single file JS file for volo that a user just puts in their path (or have multiple copies). However, node is required to run, and the user will likely want to install other npm-installed packages, like jshint, for use in their project's volofiles.

Making that process similar to how node normally operates probably outweigh my personal aversion to globally installed packages in node, the single namespace/package.json name limitations in npm, and my desire to encourage single file JS file installations for node-run utilities.

What does this mean practically?

For normal use it just means using npm to install and update volo. No more volo rejuvenate and volo acquire. Once installed via npm, volo [command] will work as before.

The change to volofiles is the biggest change. volofiles will need to do module.exports = {} instead of define(function (require) { return {} }); to take advantage of future volofile features.

The 0.2 volo will still understand the old volofile syntax though, so you do not need to change your volofiles right away. However, to get the newer inter-command dependency support and local npm-installed package support for volofiles, the new syntax will be needed.

Extreme example of the conversion:

Old format:

define(function (require) {
    //This volofile uses the 'amdify' 'q' and 'volo'github' module
    //from the modules included in volo.
    var amdify = require('amdify'),
        q = require('q'),
        github = require('volo/github');

    return {
        //Define a foo command that can be run via "volo foo"
        foo:  function (d, v, namedArgs, appName) {
            amdify();
            github();
        }
    }
});

new format:

//Any module installed in this project's node_modules
//directory can be used.
var jshint = require('jshint');

module.exports = {
    //Define a foo command that can be run via "volo foo"
    foo:  function (d, v, namedArgs, appName) {
        //Use v.require to get modules from the volo package.
        //commands are in './commands' and helper modules are
        //in './lib'. volo also ships a version of 'q'
        var amdify = v.require('./commands/amdify'),
            github = v.require('./lib/github'),
            //Could use require('q') if this project has a
            //node_modules with 'q' installed
            q = v.require('q');

        amdify();
        github();
        jshint();
    }
};

Comments are welcome. I have a proof of concept working in the prime branch, with all the tests passing.

[jrburke]

cc @dustinboston and @mstade since they have been making some volo commands. I do not think this changes things much, just a different wrapper in the internal volo commands, see the prime branch's commands directory for how they look now.

[sgentile]

I think it's a great idea

[dustinboston]

@jrburke I think it's a great move. I don't really mind using the single file, but there are a lot of nice benefits to using npm. Thanks for the heads up! BTW I've just started using git submodules. Um, they're awesome. I wonder if there would be any benefit to wrapping git add submodule and using git internals to do the updates that we were talking about?

[jrburke]

@dustinboston I hope to replace most submodule use with volo use for front end dependencies. git submodules are awful to deal with, and for the cases where you are just consuming code, not needing to modify it, the submodules junk is more confusing, particularly when you work in a few branches in a tree. By using volo, or npm for that matter and committing the node_modules contents, end consumers do not need to fiddle with git submodules, and it is much clearer what happens when switching branches.

[dustinboston]

@jrburke That makes a lot of sense. Thanks!

[jrburke]

This has been merged to master as of cfd1a9e. A few more fixes for some issues for 0.2 and the 0.2 release will go out with this structure.