I think the biggest win is to do both. i.e., have an API that makes sense to library consumers, and then have a cordova-cli-lib, which provides arg-parsing ontop of the makes-sense-to-consumers API.
On Thu, Apr 17, 2014 at 5:43 PM, Michal Mocny <[email protected]> wrote: > 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) > - ..as 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 > implementations > > 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 <[email protected]> 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. > > >
