cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Sharing code between plugman and cordova-cli
Date Mon, 14 Apr 2014 20:16:58 GMT
If we manage to get down to 1 module === 1 function then its doubtful we'd
have much advantage to the atomic commits thing. I'm cool w/ starting w/
one repo and seeing where it leads. Sort of a graduation step thing.


On Mon, Apr 14, 2014 at 12:02 PM, Michal Mocny <mmocny@chromium.org> wrote:

> Alright then, lets do 3+ npm packages: cordova (cli only), plugman (cli
> only), and cordova-lib (or something similarly named, TBD, suggestions?).
>  As cordova-lib refactors to have some useful self-contained utils, we will
> move those to dedicated npm modules published separately.
>
> However, we are currently debating the use of a single vs multiple git
> repos to hold the modules.
>
> The advantages of single repo:
> - Easier to create atomic commits to multiple npm modules (there are often
> multi-part changes), which is especially true for external Pull Requests.
> - More likely that we will be willing to move utils out to dedicated npm
> modules if there is no additional repo/release management overhead.
>
> The advantages of multiple repos:
> - Easier to isolate github issues (though we don't really use these), and
> Pull Requests.  Note: does not affect git logs, which are easy to filter
> based on subdirectory.
> - We already have cordova-cli and plugman repos anyway.
> - "Feels" cleaner?
>
> -Michal
>
>
>
>
> On Mon, Apr 14, 2014 at 2:13 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
>
> > 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