cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: CLI and cordova-lib design/extraction
Date Thu, 17 Apr 2014 21:43:02 GMT
Few considerations that come to mind right away, but I have no opinions one
way or the other yet.

Pro's for Dumber CLI:
- Easier to support liberal dependency versioning (aka, don't need weekly
CLI releases as part of cordova-lib updates)
- part of liberal deps, it may make it easier to supporting one global
CLI install support multiple cordova workspaces at different versions
(which has not been a terrible problem for us so far, but could be).
- Potentially easier for downstream CLI to be in-sync with their
functionality, if they hand off more args handling to cordova-lib

Pro's for Smarter CLI:
- cordova-lib API's can be more "formal".  Aka node style vs string arg
parsing / generic array/dict of args passing.
- ..and if cordova-lib API's are more node style, easier to build better
tools/tests for automation on top of them.
- Generic/Dumb arg parsing may be difficult (or impossible) (Mark
mentioned: especially with handling of optional positional arguments, but
may be more cases).
- ..thus current CLI interface may need to change if not all current
command formats can be handled generically (though, change may not be bad)

On Thu, Apr 17, 2014 at 5:11 PM, Brian LeRoux <> wrote:

> In another thread Michal asks,
> "How much of CLI's stay in cli: is it a *really* dumb wrapper that parses
> input
> in a generic fashion and turns it into dumb require() calls with opt's?  Or
> does it understand the full spec and massage opts into the forms
> cordova-lib-*
> expect  (both options have value!)"
> I like the idea of really dumb wrapper but would like to better understand
> the ideas with more logic (maybe api style?) in the CLI.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message