cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Sharing code between plugman and cordova-cli
Date Mon, 14 Apr 2014 18:13:55 GMT
To brian and steve's points I think it's a bad idea to move common code to
cordova-cli. I don't think we want another cordova-coho.


On Fri, Apr 11, 2014 at 5:36 PM, Brian LeRoux <b@brian.io> wrote:

> It would be very good for folks to understand the benefit of using npm is
> that we will likely only have to release these small modules very rarely.
> Once the module is out the dependency part is done. This is vastly simpler
> workflow, smaller codebases to reason about, quicker to test, and easier to
> ship small releases. If the small module is only applicable to Corodva that
> is fine and good.
>
> This is less complicated. It is easier to share code that is in modules.
> Adding them to the same repo is no different than adding it to the
> package.json and require'ing it in from a programming perspective (but it
> does add overhead of a large codebase in a single repo).
>
> Having large monolith codebases is considered a poor practice in Node based
> projects and most of Cordova today is a Node based project. I recommend
> learning more about the philosophy and reasoning for these practices. We
> don't need to 'conform' to all Node-isms (like favoring callbacks to
> promises or streams to sync i/o operations) but the committers here would
> do well to understand those primitives and the motivations for them.
>
>
>
> On Sat, Apr 12, 2014 at 5:42 AM, Mark Koudritsky <kamrik@google.com>
> wrote:
>
> > On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <stevengill97@gmail.com>
> > 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
> > cordova).
> >
>

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