Investigate volojs as a framework packaging tool

[fwenzel]

Much like playdoh vs. funfactory, we should decide whether just forking mortar is the way to go or if mortar should in itself be a command to spin up a new project directory.

volo looks like an apt solution for this purpose.

https://github.com/volojs/volo

Check out if it serves our purposes here. @jrburke should be able to answer any questions.

[jlongster]

volo looks very cool. I bet we'll end up with a very simple command to setup a new project (even one of those curl http://blah/ | sh commands, those are awesome).

I favor that instead of actually forking mortar, because this really should strictly be a template that's just copied.

[jrburke]

The curl approach is great if the target is non-Windows platforms. I'm making an effort for volo to work on windows boxes without needing to do cygwin stuff. While there is a node dependency, it is nice to have it installed for having a way to spin up a simple server.

I use it in this app template that uses twitter bootstrap and appcache:

https://github.com/volojs/create-responsive-template

it is really nice when integrating browserid, I have a fork of the project where I am playing around with that here:

https://github.com/volojs/create-responsive-template/tree/browserid

and the single file server is here:

https://github.com/volojs/create-responsive-template/blob/browserid/tools/server.js

It is just meant as a dev server, to serve the UI and implement some simple API endpoints for the browserid integration, with the hope that the developer would use something else for their production site. This would just get them started on the front end with a workable browserid approach in dev.

Anyway, some of this is drifting out of the scope of this ticket, so I'll stop now. I'm not sure what the goal of the project is, just providing some feedback based on the choices I took with the above mentioned template.

[fwenzel]

James (B): Thanks for the detailed information! Looks like the use case for mortar partially matches what you're doing there. Here is some more information about this project: https://wiki.mozilla.org/Apps/Mortar

Perhaps it makes sense to collaborate on some of this?

[jrburke]

Sure, I'm happy to help. For the 'bricks' part, I think this just gets into being able to list out what front end libraries can be used for each piece. Or having a few different templates to choose from. For instance, I'm assisting the gladiusjs mozilla folks that are working on a game template. Their needs are a bit more specialized as far as suggested libraries for things.

volo can install JS dependencies from github via volo add, so that may be useful. I expect something like that may be used for the libraries/bricks that can be used for the game template. The tricky part usually with this sort of thing is making the opinionated choices on what libraries to use.

volo create allows a project template to have a volofile with an 'onCreate' command, which has been useful to allow the project creation process to ask questions on what the user wants in to include or how to configure the template.

I'm also going to look at grunt as a command line tool option. I may just try to tie in the volo commands to be runnable as grunt commands. My main desire is to see github used as a project template repo and also as a repo for front end library code (or a way to store a pointer to where to get the library) vs. trying to wedge front end concerns into npm.

grunt is focused on having a declarative, top level JSON-like build file to avoid the async programming normally needed when running in node (delegating that to the tasks that implement the declarative commands), but I'm also trying to balance that with just having an easy way to do some quick imperative work -- so something that allows more per-project flexibility at the cost of doing imperative work.

[fwenzel]

Looks like we're done investigating, thanks!