-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider making volo a plain npm-installable node package #38
Comments
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. |
I think it's a great idea |
@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 |
@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. |
@jrburke That makes a lot of sense. Thanks! |
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. |
In the process of figuring out how to do the following:
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:
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
andvolo 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 ofdefine(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:
new format:
Comments are welcome. I have a proof of concept working in the prime branch, with all the tests passing.
The text was updated successfully, but these errors were encountered: