search

volojs / volo

Create front end projects from templates, add dependencies, and automate the resulting projects
https://volojs.github.io/
Other
1.41k stars 99 forks source link

Consider using optimist for command options parsing #96

Open mstade opened 12 years ago

mstade commented 12 years ago

Volo provides some mechanism for passing arguments to volo commands, but it's fairly limited. Would you consider incorporating something like optimist into volo? It's currently not possible to use optimist for options parsing, since process.argv inside of a volofile or command doesn't contain the arguments passed on the command line.

Since volo already recognizes the flags property in commands, maybe that could be used to leverage some of the fancier features of optimist, such as defaults and validation?

jrburke commented 12 years ago

What is not possible with the existing command line parsing in volo? Commands can implement a "validate" method to validate the values that are parsed, for example.

Also, right now the flags mechanism allows either -flag or --flag, and translating a short -f to a flag boolean value. Not a big thing though, just trying to list out what may be issues in the conversion.

I'm not opposed to switching to optimist, but want to know how things will change, what is gained/lost.

mstade commented 12 years ago

I don't think anything is lost really, more gained. For instance, it'll properly handle things like -multi and it would correctly expand to -m -u -l -t -i. Flags can be negated with the --no- convention, default values can be assigned with less typing, -- is understood as an instruction to stop parsing, complex arguments like --foo.bar will be turned into an object graph etc. As far as I can tell, there are no features that volo currently support that would be lost with optimist, but plenty that would be gained.

If you don't want to tie volo to optimist, I guess it could be hidden as an implementation detail, and just having people provide a map, much like flags but more powerful. Call it a new key, options or args or something and you've got less hassle with backwards compatibility.

Another option is to not parse things altogether and just provide the argv object, or provide it in addition to whatever parsing volo does, so people can use whatever parsing method they like. It may make things a bit inconsistent (different commands parsing things differently) but wouldn't tie volo to anything then.