CLI argument parsing as distinct node module. Like it.
On Tue, Apr 22, 2014 at 12:33 PM, Brian LeRoux wrote:
> ya I don't see those goals at odds and would love a proper node api, with
> callbacks returning an error or null as the first arg, in addition to
> something that deals w/ massaging c
ya I don't see those goals at odds and would love a proper node api, with
callbacks returning an error or null as the first arg, in addition to
something that deals w/ massaging cli input
On Tue, Apr 22, 2014 at 9:02 AM, Braden Shepherdson wrote:
> I was about to suggest exactly this. I already
I was about to suggest exactly this. I already did part of this with the
promises refactoring; we should continue it. Mixing the arg-parsing and
actual logic is no good.
Braden
On Tue, Apr 22, 2014 at 11:26 AM, Andrew Grieve wrote:
> I think the biggest win is to do both.
>
> i.e., have an API
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 wrote:
> Few considerations that come to mind rig
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 suppo
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!
