cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Koudritsky <>
Subject Re: Sharing code between plugman and cordova-cli
Date Fri, 11 Apr 2014 19:42:22 GMT
On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <> wrote:

> I'd love to get more details about your proposed first patch. What do you
> mean by "Move internal implementation details of plugman into
> cordova". I interpret it as move common functionality into cli, make
> plugman dependent on cli.

Yes, that's the intention.

> If that is the case, wouldn't it make more sense
> to move the functionality into plugman since the cli already requires it?
There is no big difference which way to move the code as long as it's easy
to share, the change is very simple either way. The cli npm package name is
"cordova" which is an argument towards keeping most of the logic there
because that's the name people know. For users the change will be
transparent, plugman users will continue to "npm install plugman" and cli
users will continue to "npm install cordova".

I like the end goals of your proposal, in that we are working towards
> smaller modules. I'm not sure if moving components from one repo to another
> is a better way to reach the end goal, instead of Mark's original
> suggestion of a third cordova-lib repo that both plugman + cli can depend
> on.

The end goal of my proposal is simplified development workflow without
complicating release workflow.

Right now I'm working on a new piece of code (dealing with plugin deps and
versions) that should be used in both plugman and cli. While it seems like
it should be trivial, at a closer look there is currently no clean way to
share such code between cli and plugman (just like xml helpers are cloned).
At this stage that piece of code is nowhere close to being ready for
release as a separate small module, but it has a good potential to
eventually become such module (though it will never be usable outside

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