cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Sharing code between plugman and cordova-cli
Date Tue, 15 Apr 2014 13:36:10 GMT
I think everyone is on board with the idea that modules should be used to
enable sharing code, and for code organization.

Two problems that are happening in practice:
- Multiple pull requests (plugman and CLI) to make a change
- Code duplication between the repositories

Both of these are solved by moving all common code into the same git
repository.

I think whether to make additional npm packages should happen as a
follow-up, and as concrete proposals (e.g. Let's publish CordovaError into
an npm package)

It's a bit weird that a lot of cordova's CLI is in a module called
"cordova", but you need to install "plugman" to publish to the registry.

Analogy: there's not an "npm-cli" separate from "npm-publisher".

How about folding the functionality of plugman into cordova?
- "cordova publish"
- "cordova owner add"
- "cordova plugin add --platform
<ios|amazon-fireos|android|blackberry10|wp7|wp8> --project <directory>
--plugin <name|url|path> [--plugins_dir <directory>] [--www <directory>]
[--variable <name>=<value> [--variable <name>=<value> ...]]

This would:
- Only one tool for devs to install (aptly named "cordova")
   - "cordova --help" as one entry-point to what's available
- Simply release process
   - Fewer release steps
   - Single set of release notes (no more having to duplicate fixes to
plugman in CLI's release notes)

For users that are accustomed to using plugman directly, we could make
plugman depend on CLI to have it continue working.

On Mon, Apr 14, 2014 at 12:16 PM, Brian LeRoux <b@brian.io> wrote:

> 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