Sharing code between plugman and cordova-cli

[Mark Koudritsky <ka...@google.com>]

I often find myself making changes that require commits to both plugman and
cli, it’s not always clear which repo new code should live in and sharing
utility functions between the two projects is not trivial.

The idea of “cordova-lib” was mentioned several times on this mailing list.
The lib would contain most of the code from both plugman and cli while the
end tools will be thin wrappers around the lib.

I wanted to probe how people working on CLI feel about such rearrangement.

But if we are already in this discussion, now that the heavy platforms
files are distributed separately from cordova-cli (repos like cordova-ios
etc), is there anything that prevents us from merging plugman and cli into
a single npm package with 2 executables?


Examples of code that should be shared include:
- Common logging and error handling logic (e.g. CordovaError exception)
- Fetching logic (for plugins and platforms)
- Platform-specific logic (e.g. where the config.xml file lives within each
project)
- Generic utilities like xml-helpers.js (currently copied but slightly
diverged in the 2 repos)

The first option that comes to mind is to create another repo and another
npm package for cordova-lib, but this creates significant overhead:
 - Version release would get more difficult (see the failed release vote
thread <https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html>from
last Friday)
 - In many cases new functionality in plugman or CLI would require changes
in 2 or even 3 repos. This is a significant additional barrier for new
contributors that don’t have commit rights - coordinating two
interdependent pull request is quite a hassle.
 - Strictly speaking, cordova-lib major version number will have to be
bumped every time we change some function signatures, which will happen
rather frequently in this case (this point also partially holds true if the
lib will be part of the plugman repo and npm package).

Based on the points above a single repo and npm package containing both
plugman and cli seems to provide the most benefit.

What do you think?

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

I realize now that is all we're talking about.

/cordova-the-one-repo-to-rule-them-all
|- cli
|  '- package.json
|- plugman
|  '- package.json
|- etc..

The benefit being it will be faster to rip things into module packages from
one directly I guess if your text editor struggles with many directories
(Is this th problem?) I completely do not follow the reasoning. Commit
history is in one place is a benefit though I personally don't find myself
rewinding time very often (and when I do I find such exercises easier in
small modules.)



On Tue, Apr 15, 2014 at 6:21 PM, Carlos Santana <cs...@gmail.com>wrote:

> On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana <csantana23@gmail.com
> >wrote:
>
> > I agree that braking things into small node modules with clear scope and
> > function is good and then be shared across other modules that declare
> them
> > ad dependencies.
> >
> > These common node modules...:
> > 1. don't have to be publish to npm or release as a apache/cordova dist
> > asset.
> > 2. can live in their own git repos
> > 3. can be specified as dependencies using git url, manage during dev with
> > npm link or git submodules to do test integration while doing dev
> > 4. can be treated as common source code to the cordova tools, and not a
> > standalone general purpose tool
> > 5. what actually gets publish to npm and release as a apache/cordova dist
> > asset continue to be plugman and cordova-cli
> >
> > --Carlos
> >
> >
> This was just things to consider not necessary a proposal.
> But wanted to point out that things can be broken up into modules, and not
> necessary add overhead on npm and release process/voting, and just treated
> as a SCM exercise.
>

Re: Sharing code between plugman and cordova-cli

[Carlos Santana <cs...@gmail.com>]

npm link is the life saver when working with multiple node modules that you
own and have dependencies between them.



On Wed, Apr 16, 2014 at 10:45 AM, Mark Koudritsky <ka...@google.com> wrote:

> On Wed, Apr 16, 2014 at 9:59 AM, Carlos Santana <csantana23@gmail.com
> >wrote:
>
> > If you the decision factor is to consolidate all the cli tooling into a
> > single git repo, that's ok but
> >
> > I still think we should treat what's inside the single repo as different
> > small independent npm modules and use the bundleDependencies in the cli
> and
> > plugman pacakge.json
> >
> > /cordova-the-one-repo-to-rule-them-all
> > |- cli
> > |  '- package.json
> > |- plugman
> > |  '- package.json
> > |- common
> > |  '-util_a/package.json
> > |  '-util_b/package.json
> > |  '-util_c/package.json
> >
> > cli and plugman pacakge.json will contain
> > "bundleDependencies": [
> >     "util_a",
> >     "util_b"
> >     ]
> >
> > during dev and plublish, coho can automate
> > cd cli
> > #link dependencies
> > npm link ../common/util_a
> > npm link ../common/util_b
>
>
> The bundleDependencies method seems good, didn't know about it.
>
> What happens if util_c also depends on util_a?
> I think in that case you I'll need to cd to util_c and also do some linking
> magic there. I guess we'll need a script (or several) for setting up the
> dev environment.
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Sharing code between plugman and cordova-cli

[Mark Koudritsky <ka...@google.com>]

On Wed, Apr 16, 2014 at 9:59 AM, Carlos Santana <cs...@gmail.com>wrote:

> If you the decision factor is to consolidate all the cli tooling into a
> single git repo, that's ok but
>
> I still think we should treat what's inside the single repo as different
> small independent npm modules and use the bundleDependencies in the cli and
> plugman pacakge.json
>
> /cordova-the-one-repo-to-rule-them-all
> |- cli
> |  '- package.json
> |- plugman
> |  '- package.json
> |- common
> |  '-util_a/package.json
> |  '-util_b/package.json
> |  '-util_c/package.json
>
> cli and plugman pacakge.json will contain
> "bundleDependencies": [
>     "util_a",
>     "util_b"
>     ]
>
> during dev and plublish, coho can automate
> cd cli
> #link dependencies
> npm link ../common/util_a
> npm link ../common/util_b


The bundleDependencies method seems good, didn't know about it.

What happens if util_c also depends on util_a?
I think in that case you I'll need to cd to util_c and also do some linking
magic there. I guess we'll need a script (or several) for setting up the
dev environment.

Re: Sharing code between plugman and cordova-cli

[Carlos Santana <cs...@gmail.com>]

If you the decision factor is to consolidate all the cli tooling into a
single git repo, that's ok but

I still think we should treat what's inside the single repo as different
small independent npm modules and use the bundleDependencies in the cli and
plugman pacakge.json

/cordova-the-one-repo-to-rule-them-all
|- cli
|  '- package.json
|- plugman
|  '- package.json
|- common
|  '-util_a/package.json
|  '-util_b/package.json
|  '-util_c/package.json

cli and plugman pacakge.json will contain
"bundleDependencies": [
    "util_a",
    "util_b"
    ]

during dev and plublish, coho can automate
cd cli
#link dependencies
npm link ../common/util_a
npm link ../common/util_b
#code and test cli
#npm pack or publish cli
npm publish

what's get "npm pack" or "npm publish" will publish the cli files with the
bundledependencies.
When user "npm install cli" npm will see that it contains bundle
dependencies, and will not try to fetch and install them assuming that they
already included.

my take is the small modules are usable outside from cli an plugman, then I
think is better to versioned them and published them to npm as independent
modules, but keep them in the large single repo.
But take into account that we need to be good citizens if we release this
small npm pacakges because people are going to expect to be maintain.




On Tue, Apr 15, 2014 at 9:42 PM, Carlos Santana <cs...@gmail.com>wrote:

> You don't need git install for npm to resolved the dependency, npm handles
> the fetching of the git url or simple url to tarball [1]
>
> Another way is when is time to publish you can put these common node
> modules as Bundle Dependencies [2] and send them to npm when publishing
> plugman and cordova-cli
>
> I understand that the problem is the common code to be separated and into
> a common component.
>
> I just want to point out that there is more than one way of accomplish our
> goals, and that npm has a lot capabilities of accomplishing the same thing
> with different approaches.
>
> 1: https://www.npmjs.org/doc/json.html#URLs-as-Dependencies
> 2: https://www.npmjs.org/doc/json.html#bundledDependencies
>
> --Carlos
>
>
>
>
> On Tue, Apr 15, 2014 at 9:32 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> We found out the hard way that having any git-based dependencies
>> causes install to fail if the user doesn't have git installed. For
>> this reason, if something's going to be an npm modules that's depended
>> on, it must be published to npm, and thus go through the proper
>> release process.
>>
>> Note though that the release process isn't the motivator for this,
>> rather, it's the pain of co-ordinating changes to multiple
>> repositories that depend on each other.
>>
>>
>>
>> On Tue, Apr 15, 2014 at 5:21 PM, Carlos Santana <cs...@gmail.com>
>> wrote:
>> > On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana <csantana23@gmail.com
>> >wrote:
>> >
>> >> I agree that braking things into small node modules with clear scope
>> and
>> >> function is good and then be shared across other modules that declare
>> them
>> >> ad dependencies.
>> >>
>> >> These common node modules...:
>> >> 1. don't have to be publish to npm or release as a apache/cordova dist
>> >> asset.
>> >> 2. can live in their own git repos
>> >> 3. can be specified as dependencies using git url, manage during dev
>> with
>> >> npm link or git submodules to do test integration while doing dev
>> >> 4. can be treated as common source code to the cordova tools, and not a
>> >> standalone general purpose tool
>> >> 5. what actually gets publish to npm and release as a apache/cordova
>> dist
>> >> asset continue to be plugman and cordova-cli
>> >>
>> >> --Carlos
>> >>
>> >>
>> > This was just things to consider not necessary a proposal.
>> > But wanted to point out that things can be broken up into modules, and
>> not
>> > necessary add overhead on npm and release process/voting, and just
>> treated
>> > as a SCM exercise.
>>
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Sharing code between plugman and cordova-cli

[Carlos Santana <cs...@gmail.com>]

You don't need git install for npm to resolved the dependency, npm handles
the fetching of the git url or simple url to tarball [1]

Another way is when is time to publish you can put these common node
modules as Bundle Dependencies [2] and send them to npm when publishing
plugman and cordova-cli

I understand that the problem is the common code to be separated and into a
common component.

I just want to point out that there is more than one way of accomplish our
goals, and that npm has a lot capabilities of accomplishing the same thing
with different approaches.

1: https://www.npmjs.org/doc/json.html#URLs-as-Dependencies
2: https://www.npmjs.org/doc/json.html#bundledDependencies

--Carlos




On Tue, Apr 15, 2014 at 9:32 PM, Andrew Grieve <ag...@chromium.org> wrote:

> We found out the hard way that having any git-based dependencies
> causes install to fail if the user doesn't have git installed. For
> this reason, if something's going to be an npm modules that's depended
> on, it must be published to npm, and thus go through the proper
> release process.
>
> Note though that the release process isn't the motivator for this,
> rather, it's the pain of co-ordinating changes to multiple
> repositories that depend on each other.
>
>
>
> On Tue, Apr 15, 2014 at 5:21 PM, Carlos Santana <cs...@gmail.com>
> wrote:
> > On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana <csantana23@gmail.com
> >wrote:
> >
> >> I agree that braking things into small node modules with clear scope and
> >> function is good and then be shared across other modules that declare
> them
> >> ad dependencies.
> >>
> >> These common node modules...:
> >> 1. don't have to be publish to npm or release as a apache/cordova dist
> >> asset.
> >> 2. can live in their own git repos
> >> 3. can be specified as dependencies using git url, manage during dev
> with
> >> npm link or git submodules to do test integration while doing dev
> >> 4. can be treated as common source code to the cordova tools, and not a
> >> standalone general purpose tool
> >> 5. what actually gets publish to npm and release as a apache/cordova
> dist
> >> asset continue to be plugman and cordova-cli
> >>
> >> --Carlos
> >>
> >>
> > This was just things to consider not necessary a proposal.
> > But wanted to point out that things can be broken up into modules, and
> not
> > necessary add overhead on npm and release process/voting, and just
> treated
> > as a SCM exercise.
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Sharing code between plugman and cordova-cli

[Andrew Grieve <ag...@chromium.org>]

We found out the hard way that having any git-based dependencies
causes install to fail if the user doesn't have git installed. For
this reason, if something's going to be an npm modules that's depended
on, it must be published to npm, and thus go through the proper
release process.

Note though that the release process isn't the motivator for this,
rather, it's the pain of co-ordinating changes to multiple
repositories that depend on each other.



On Tue, Apr 15, 2014 at 5:21 PM, Carlos Santana <cs...@gmail.com> wrote:
> On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana <cs...@gmail.com>wrote:
>
>> I agree that braking things into small node modules with clear scope and
>> function is good and then be shared across other modules that declare them
>> ad dependencies.
>>
>> These common node modules...:
>> 1. don't have to be publish to npm or release as a apache/cordova dist
>> asset.
>> 2. can live in their own git repos
>> 3. can be specified as dependencies using git url, manage during dev with
>> npm link or git submodules to do test integration while doing dev
>> 4. can be treated as common source code to the cordova tools, and not a
>> standalone general purpose tool
>> 5. what actually gets publish to npm and release as a apache/cordova dist
>> asset continue to be plugman and cordova-cli
>>
>> --Carlos
>>
>>
> This was just things to consider not necessary a proposal.
> But wanted to point out that things can be broken up into modules, and not
> necessary add overhead on npm and release process/voting, and just treated
> as a SCM exercise.

Re: Sharing code between plugman and cordova-cli

[Carlos Santana <cs...@gmail.com>]

On Tue, Apr 15, 2014 at 9:07 PM, Carlos Santana <cs...@gmail.com>wrote:

> I agree that braking things into small node modules with clear scope and
> function is good and then be shared across other modules that declare them
> ad dependencies.
>
> These common node modules...:
> 1. don't have to be publish to npm or release as a apache/cordova dist
> asset.
> 2. can live in their own git repos
> 3. can be specified as dependencies using git url, manage during dev with
> npm link or git submodules to do test integration while doing dev
> 4. can be treated as common source code to the cordova tools, and not a
> standalone general purpose tool
> 5. what actually gets publish to npm and release as a apache/cordova dist
> asset continue to be plugman and cordova-cli
>
> --Carlos
>
>
This was just things to consider not necessary a proposal.
But wanted to point out that things can be broken up into modules, and not
necessary add overhead on npm and release process/voting, and just treated
as a SCM exercise.

Re: Sharing code between plugman and cordova-cli

[Carlos Santana <cs...@gmail.com>]

I agree that braking things into small node modules with clear scope and
function is good and then be shared across other modules that declare them
ad dependencies.

These common node modules...:
1. don't have to be publish to npm or release as a apache/cordova dist
asset.
2. can live in their own git repos
3. can be specified as dependencies using git url, manage during dev with
npm link or git submodules to do test integration while doing dev
4. can be treated as common source code to the cordova tools, and not a
standalone general purpose tool
5. what actually gets publish to npm and release as a apache/cordova dist
asset continue to be plugman and cordova-cli

--Carlos




On Tue, Apr 15, 2014 at 5:52 PM, Brian LeRoux <b...@brian.io> wrote:

> I really hope we don't have to vote on this. Its the wrong path guys and I
> am really hoping we can find consensus to follow Node practices in a Node
> project. I recognize that Google is used to working with a single large
> repo but this is not Google.
>
>
> On Wed, Apr 16, 2014 at 9:41 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > I should have updated this email thread.  That proposal is old news, Mark
> > has done a writeup:
> >
> >
> https://docs.google.com/document/d/1GVtG6BD266dqRURKaS-GEDefb0tBYt56acxrJEKAfmE/edit
> >
> >
> > (I know you have commented on it already, but for others)
> >
> > On Tue, Apr 15, 2014 at 4:20 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > >
> > > > I think everyone is on board with the idea that modules should be
> used
> > to
> > > > enable sharing code, and for code organization.
> > > >
> > >
> > > Cool.
> > >
> > >
> > > > 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.
> > > >
> > >
> > > Nope. Multiple pull requests to make a single functional change could
> be
> > > achieved by pulling a common module out. I respect you have a single
> repo
> > > at Google but this is not the solution to everything!
> > >
> > >
> > >
> > >
> > > > 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)
> > > >
> > >
> > > Sure
> > >
> > >
> > > 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.
> > > >
> > >
> > > Nope. The choice to make the CLI the entry point for developers of
> > cordova
> > > makes perfect sense. To have a separate tool for publishing also makes
> > > sense. Exposing that tool from Cordova was always the idea.
> > >
> > >
> > >
> > > > How about folding the functionality of plugman into cordova?
> > > >
> > >
> > > Right. This doesn't mean they have to be in the same git repo. In
> Cordova
> > > you can use package.json to include Plugman and expose functionality.
> > This
> > > way you win versioning which is the point dependency management…not
> SCM.
> > >
> > >
> > > > For users that are accustomed to using plugman directly, we could
> make
> > > > plugman depend on CLI to have it continue working.
> > > >
> > >
> > > What?! Why!
> > >
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

I really hope we don't have to vote on this. Its the wrong path guys and I
am really hoping we can find consensus to follow Node practices in a Node
project. I recognize that Google is used to working with a single large
repo but this is not Google.


On Wed, Apr 16, 2014 at 9:41 AM, Michal Mocny <mm...@chromium.org> wrote:

> I should have updated this email thread.  That proposal is old news, Mark
> has done a writeup:
>
> https://docs.google.com/document/d/1GVtG6BD266dqRURKaS-GEDefb0tBYt56acxrJEKAfmE/edit
>
>
> (I know you have commented on it already, but for others)
>
> On Tue, Apr 15, 2014 at 4:20 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > >
> > > I think everyone is on board with the idea that modules should be used
> to
> > > enable sharing code, and for code organization.
> > >
> >
> > Cool.
> >
> >
> > > 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.
> > >
> >
> > Nope. Multiple pull requests to make a single functional change could be
> > achieved by pulling a common module out. I respect you have a single repo
> > at Google but this is not the solution to everything!
> >
> >
> >
> >
> > > 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)
> > >
> >
> > Sure
> >
> >
> > 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.
> > >
> >
> > Nope. The choice to make the CLI the entry point for developers of
> cordova
> > makes perfect sense. To have a separate tool for publishing also makes
> > sense. Exposing that tool from Cordova was always the idea.
> >
> >
> >
> > > How about folding the functionality of plugman into cordova?
> > >
> >
> > Right. This doesn't mean they have to be in the same git repo. In Cordova
> > you can use package.json to include Plugman and expose functionality.
> This
> > way you win versioning which is the point dependency management…not SCM.
> >
> >
> > > For users that are accustomed to using plugman directly, we could make
> > > plugman depend on CLI to have it continue working.
> > >
> >
> > What?! Why!
> >
>

Re: Sharing code between plugman and cordova-cli

[Michal Mocny <mm...@chromium.org>]

I should have updated this email thread.  That proposal is old news, Mark
has done a writeup:
https://docs.google.com/document/d/1GVtG6BD266dqRURKaS-GEDefb0tBYt56acxrJEKAfmE/edit


(I know you have commented on it already, but for others)

On Tue, Apr 15, 2014 at 4:20 PM, Brian LeRoux <b...@brian.io> wrote:

> >
> > I think everyone is on board with the idea that modules should be used to
> > enable sharing code, and for code organization.
> >
>
> Cool.
>
>
> > 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.
> >
>
> Nope. Multiple pull requests to make a single functional change could be
> achieved by pulling a common module out. I respect you have a single repo
> at Google but this is not the solution to everything!
>
>
>
>
> > 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)
> >
>
> Sure
>
>
> 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.
> >
>
> Nope. The choice to make the CLI the entry point for developers of cordova
> makes perfect sense. To have a separate tool for publishing also makes
> sense. Exposing that tool from Cordova was always the idea.
>
>
>
> > How about folding the functionality of plugman into cordova?
> >
>
> Right. This doesn't mean they have to be in the same git repo. In Cordova
> you can use package.json to include Plugman and expose functionality. This
> way you win versioning which is the point dependency management…not SCM.
>
>
> > For users that are accustomed to using plugman directly, we could make
> > plugman depend on CLI to have it continue working.
> >
>
> What?! Why!
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

>
> I think everyone is on board with the idea that modules should be used to
> enable sharing code, and for code organization.
>

Cool.


> 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.
>

Nope. Multiple pull requests to make a single functional change could be
achieved by pulling a common module out. I respect you have a single repo
at Google but this is not the solution to everything!




> 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)
>

Sure


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.
>

Nope. The choice to make the CLI the entry point for developers of cordova
makes perfect sense. To have a separate tool for publishing also makes
sense. Exposing that tool from Cordova was always the idea.



> How about folding the functionality of plugman into cordova?
>

Right. This doesn't mean they have to be in the same git repo. In Cordova
you can use package.json to include Plugman and expose functionality. This
way you win versioning which is the point dependency management…not SCM.


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

What?! Why!

RE: Sharing code between plugman and cordova-cli

[Jonathan Bond-Caron <jb...@gdesolutions.com>]

On Tue Apr 15 09:36 AM, Andrew Grieve wrote:
> 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
> 

+1, from a new contributor's perspective, learning about git & coordinating pull requests to 2+ repos was quite challenging. Probably equally challenging to review :) 

> - Only one tool for devs to install (aptly named "cordova")
>    - "cordova --help" as one entry-point to what's available

Like this, with cordova-lib or cordova-common being a reasonable transition to help clarify how or if plugman should be merged. 

Re: Sharing code between plugman and cordova-cli

[Michal Mocny <mm...@chromium.org>]

I like the clear distinction of plugman workflow vs cordova workflow, so I
wouldn't want to drop the separation.  If this goes well, the contents of
plugman (and cordova) will be argument parsing, help/usage messages, and
forwarding into cordova-lib, so they will not need updating often unless
the interface changes.

I do like to proposal to add plugin publishing functionality to
cordova-cli, which we can easily do once we have a common cordova-lib which
both cli call into.  Lets leave that for a follow-on task after the
restructuring (filed: CB-6447).

-Michal


On Tue, Apr 15, 2014 at 9:36 AM, Andrew Grieve <ag...@chromium.org> wrote:

> 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 <mm...@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 <an...@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).
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Andrew Grieve <ag...@chromium.org>]

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 <mm...@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 <an...@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 <ka...@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).
> > > > >
> > > >
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

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 <mm...@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 <an...@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 <ka...@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).
> > > >
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Michal Mocny <mm...@chromium.org>]

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 <an...@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 <ka...@google.com>
> > wrote:
> >
> > > On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <st...@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).
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Anis KADRI <an...@gmail.com>]

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 <ka...@google.com>
> wrote:
>
> > On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <st...@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).
> >
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

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 <ka...@google.com> wrote:

> On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <st...@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).
>

Re: Sharing code between plugman and cordova-cli

[Mark Koudritsky <ka...@google.com>]

On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <st...@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).

Re: Sharing code between plugman and cordova-cli

[Steven Gill <st...@gmail.com>]

I agree that our agenda for next week's hangout is long enough already.

In terms of releases being infeasible, I'm assuming you mean the fact we
would have to vote on all of the components during a tools release. If we
get some of these components stable enough, we would only need to vote on
them when we change them (shouldn't be often) and not every tools release.

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. If that is the case, wouldn't it make more sense
to move the functionality into plugman since the cli already requires it?

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.


On Fri, Apr 11, 2014 at 11:44 AM, Michal Mocny <mm...@chromium.org> wrote:

> Brian,
>
> Discussed this with Mark locally.  We think you are right, if a
> library/util has use outside of plugman/cli we should compartmentalize and
> publish to npm.  At the moment, the overhead of doing releases would make
> this infeasible, and we should really plan ways to make this workflow
> possible.  I think the list of topics for next meetup is already long, so
> lets add this to agenda for a future meetup (I doubt we have any
> suggestions to fix the issue yet, anyway, we still have to automate how we
> do core releases).
>
> So, here is our proposal:
> First patches: Move internal implementation details of plugman into
> cordova, leaving the CLI parsing, usage/help, and binary in that repo, so
> it works 100% the same, except the require() paths change.
> Next patches: move out existing common utilities from cordova/plugman into
> subdirectories with names like cordova-util-foo.
> Ongoing patches: refactor more of cordova/plugman to use standalone utils.
> Eventually, when things settle: publish those utils which are useful
> outside of cli/plugman.
>
> Mark has agreed to try these first steps in a feature branch of
> plugman/cli, and will post once there is a working version.
>
> Any objections/suggestions?
>
>
> On Thu, Apr 10, 2014 at 8:05 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > More on this approach:
> >
> > http://blog.izs.me/post/48281998870/unix-philosophy-and-node-js
> > https://blog.nodejitsu.com/the-nodejs-philosophy/
> > http://substack.net/how_I_write_modules
> >
> >
> > On Fri, Apr 11, 2014 at 10:04 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > I want more repos not less! I'd love for us to break the functionality
> up
> > > into a tonne of smaller utility repos. Ideally every module is in a
> > > discreet git repo, separately versioned, and dependencies are managed
> > with
> > > npm.
> > >
> > >
> > > On Fri, Apr 11, 2014 at 5:59 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > >> The overhead of a third repo scares me.  I'm fine with merging into a
> > >> single repo, but I'll throw a third option into the mix:
> > >>
> > >> - Leave the plugman repo, and leave the plugman binary in there, but
> > >> refactor to make plugman depend on cordova-cli, and forward all
> > >> functionality to cli implementations.
> > >>
> > >> This leaves the APIs entirely untouched and is just an internal
> > refactor.
> > >>  It would invert the "depends" direction, but I don't think that
> > matters.
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <ka...@google.com>
> > >> wrote:
> > >>
> > >> > I often find myself making changes that require commits to both
> > plugman
> > >> and
> > >> > cli, it's not always clear which repo new code should live in and
> > >> sharing
> > >> > utility functions between the two projects is not trivial.
> > >> >
> > >> > The idea of "cordova-lib" was mentioned several times on this
> mailing
> > >> list.
> > >> > The lib would contain most of the code from both plugman and cli
> while
> > >> the
> > >> > end tools will be thin wrappers around the lib.
> > >> >
> > >> > I wanted to probe how people working on CLI feel about such
> > >> rearrangement.
> > >> >
> > >> > But if we are already in this discussion, now that the heavy
> platforms
> > >> > files are distributed separately from cordova-cli (repos like
> > >> cordova-ios
> > >> > etc), is there anything that prevents us from merging plugman and
> cli
> > >> into
> > >> > a single npm package with 2 executables?
> > >> >
> > >> >
> > >> > Examples of code that should be shared include:
> > >> > - Common logging and error handling logic (e.g. CordovaError
> > exception)
> > >> > - Fetching logic (for plugins and platforms)
> > >> > - Platform-specific logic (e.g. where the config.xml file lives
> within
> > >> each
> > >> > project)
> > >> > - Generic utilities like xml-helpers.js (currently copied but
> slightly
> > >> > diverged in the 2 repos)
> > >> >
> > >> > The first option that comes to mind is to create another repo and
> > >> another
> > >> > npm package for cordova-lib, but this creates significant overhead:
> > >> >  - Version release would get more difficult (see the failed release
> > vote
> > >> > thread <
> > >> https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html
> > >> > >from
> > >> > last Friday)
> > >> >  - In many cases new functionality in plugman or CLI would require
> > >> changes
> > >> > in 2 or even 3 repos. This is a significant additional barrier for
> new
> > >> > contributors that don't have commit rights - coordinating two
> > >> > interdependent pull request is quite a hassle.
> > >> >  - Strictly speaking, cordova-lib major version number will have to
> be
> > >> > bumped every time we change some function signatures, which will
> > happen
> > >> > rather frequently in this case (this point also partially holds true
> > if
> > >> the
> > >> > lib will be part of the plugman repo and npm package).
> > >> >
> > >> > Based on the points above a single repo and npm package containing
> > both
> > >> > plugman and cli seems to provide the most benefit.
> > >> >
> > >> > What do you think?
> > >> >
> > >>
> > >
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Anis KADRI <an...@gmail.com>]

I am glad that you guys agree. It's easier to maintain small modules. Also
the other workflow is still on the table as well (use of IDEs, native dev,
etc...).

I disagree with the proposal though. I think we should do it right the
first time. Move common code into its own lib (xml-helpers, log,
cli-parsing, etc...). Adding cli as plugman dependency doesn't make any
sense. If anything cli should get lighter not heavier in my opinion.

I am not saying we should move common code into plugman either, I am saying
we should request a new repository (cordova-common for example) and commit
code to it. In the meantime, if the effort starts right away one can use
github or some other service.

Anis


On Fri, Apr 11, 2014 at 10:44 AM, Michal Mocny <mm...@chromium.org> wrote:

> Brian,
>
> Discussed this with Mark locally.  We think you are right, if a
> library/util has use outside of plugman/cli we should compartmentalize and
> publish to npm.  At the moment, the overhead of doing releases would make
> this infeasible, and we should really plan ways to make this workflow
> possible.  I think the list of topics for next meetup is already long, so
> lets add this to agenda for a future meetup (I doubt we have any
> suggestions to fix the issue yet, anyway, we still have to automate how we
> do core releases).
>
> So, here is our proposal:
> First patches: Move internal implementation details of plugman into
> cordova, leaving the CLI parsing, usage/help, and binary in that repo, so
> it works 100% the same, except the require() paths change.
> Next patches: move out existing common utilities from cordova/plugman into
> subdirectories with names like cordova-util-foo.
> Ongoing patches: refactor more of cordova/plugman to use standalone utils.
> Eventually, when things settle: publish those utils which are useful
> outside of cli/plugman.
>
> Mark has agreed to try these first steps in a feature branch of
> plugman/cli, and will post once there is a working version.
>
> Any objections/suggestions?
>
>
> On Thu, Apr 10, 2014 at 8:05 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > More on this approach:
> >
> > http://blog.izs.me/post/48281998870/unix-philosophy-and-node-js
> > https://blog.nodejitsu.com/the-nodejs-philosophy/
> > http://substack.net/how_I_write_modules
> >
> >
> > On Fri, Apr 11, 2014 at 10:04 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > I want more repos not less! I'd love for us to break the functionality
> up
> > > into a tonne of smaller utility repos. Ideally every module is in a
> > > discreet git repo, separately versioned, and dependencies are managed
> > with
> > > npm.
> > >
> > >
> > > On Fri, Apr 11, 2014 at 5:59 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > >> The overhead of a third repo scares me.  I'm fine with merging into a
> > >> single repo, but I'll throw a third option into the mix:
> > >>
> > >> - Leave the plugman repo, and leave the plugman binary in there, but
> > >> refactor to make plugman depend on cordova-cli, and forward all
> > >> functionality to cli implementations.
> > >>
> > >> This leaves the APIs entirely untouched and is just an internal
> > refactor.
> > >>  It would invert the "depends" direction, but I don't think that
> > matters.
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <ka...@google.com>
> > >> wrote:
> > >>
> > >> > I often find myself making changes that require commits to both
> > plugman
> > >> and
> > >> > cli, it's not always clear which repo new code should live in and
> > >> sharing
> > >> > utility functions between the two projects is not trivial.
> > >> >
> > >> > The idea of "cordova-lib" was mentioned several times on this
> mailing
> > >> list.
> > >> > The lib would contain most of the code from both plugman and cli
> while
> > >> the
> > >> > end tools will be thin wrappers around the lib.
> > >> >
> > >> > I wanted to probe how people working on CLI feel about such
> > >> rearrangement.
> > >> >
> > >> > But if we are already in this discussion, now that the heavy
> platforms
> > >> > files are distributed separately from cordova-cli (repos like
> > >> cordova-ios
> > >> > etc), is there anything that prevents us from merging plugman and
> cli
> > >> into
> > >> > a single npm package with 2 executables?
> > >> >
> > >> >
> > >> > Examples of code that should be shared include:
> > >> > - Common logging and error handling logic (e.g. CordovaError
> > exception)
> > >> > - Fetching logic (for plugins and platforms)
> > >> > - Platform-specific logic (e.g. where the config.xml file lives
> within
> > >> each
> > >> > project)
> > >> > - Generic utilities like xml-helpers.js (currently copied but
> slightly
> > >> > diverged in the 2 repos)
> > >> >
> > >> > The first option that comes to mind is to create another repo and
> > >> another
> > >> > npm package for cordova-lib, but this creates significant overhead:
> > >> >  - Version release would get more difficult (see the failed release
> > vote
> > >> > thread <
> > >> https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html
> > >> > >from
> > >> > last Friday)
> > >> >  - In many cases new functionality in plugman or CLI would require
> > >> changes
> > >> > in 2 or even 3 repos. This is a significant additional barrier for
> new
> > >> > contributors that don't have commit rights - coordinating two
> > >> > interdependent pull request is quite a hassle.
> > >> >  - Strictly speaking, cordova-lib major version number will have to
> be
> > >> > bumped every time we change some function signatures, which will
> > happen
> > >> > rather frequently in this case (this point also partially holds true
> > if
> > >> the
> > >> > lib will be part of the plugman repo and npm package).
> > >> >
> > >> > Based on the points above a single repo and npm package containing
> > both
> > >> > plugman and cli seems to provide the most benefit.
> > >> >
> > >> > What do you think?
> > >> >
> > >>
> > >
> > >
> >
>

Re: Sharing code between plugman and cordova-cli

[Michal Mocny <mm...@chromium.org>]

Brian,

Discussed this with Mark locally.  We think you are right, if a
library/util has use outside of plugman/cli we should compartmentalize and
publish to npm.  At the moment, the overhead of doing releases would make
this infeasible, and we should really plan ways to make this workflow
possible.  I think the list of topics for next meetup is already long, so
lets add this to agenda for a future meetup (I doubt we have any
suggestions to fix the issue yet, anyway, we still have to automate how we
do core releases).

So, here is our proposal:
First patches: Move internal implementation details of plugman into
cordova, leaving the CLI parsing, usage/help, and binary in that repo, so
it works 100% the same, except the require() paths change.
Next patches: move out existing common utilities from cordova/plugman into
subdirectories with names like cordova-util-foo.
Ongoing patches: refactor more of cordova/plugman to use standalone utils.
Eventually, when things settle: publish those utils which are useful
outside of cli/plugman.

Mark has agreed to try these first steps in a feature branch of
plugman/cli, and will post once there is a working version.

Any objections/suggestions?


On Thu, Apr 10, 2014 at 8:05 PM, Brian LeRoux <b...@brian.io> wrote:

> More on this approach:
>
> http://blog.izs.me/post/48281998870/unix-philosophy-and-node-js
> https://blog.nodejitsu.com/the-nodejs-philosophy/
> http://substack.net/how_I_write_modules
>
>
> On Fri, Apr 11, 2014 at 10:04 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I want more repos not less! I'd love for us to break the functionality up
> > into a tonne of smaller utility repos. Ideally every module is in a
> > discreet git repo, separately versioned, and dependencies are managed
> with
> > npm.
> >
> >
> > On Fri, Apr 11, 2014 at 5:59 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> >> The overhead of a third repo scares me.  I'm fine with merging into a
> >> single repo, but I'll throw a third option into the mix:
> >>
> >> - Leave the plugman repo, and leave the plugman binary in there, but
> >> refactor to make plugman depend on cordova-cli, and forward all
> >> functionality to cli implementations.
> >>
> >> This leaves the APIs entirely untouched and is just an internal
> refactor.
> >>  It would invert the "depends" direction, but I don't think that
> matters.
> >>
> >> -Michal
> >>
> >>
> >> On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <ka...@google.com>
> >> wrote:
> >>
> >> > I often find myself making changes that require commits to both
> plugman
> >> and
> >> > cli, it's not always clear which repo new code should live in and
> >> sharing
> >> > utility functions between the two projects is not trivial.
> >> >
> >> > The idea of "cordova-lib" was mentioned several times on this mailing
> >> list.
> >> > The lib would contain most of the code from both plugman and cli while
> >> the
> >> > end tools will be thin wrappers around the lib.
> >> >
> >> > I wanted to probe how people working on CLI feel about such
> >> rearrangement.
> >> >
> >> > But if we are already in this discussion, now that the heavy platforms
> >> > files are distributed separately from cordova-cli (repos like
> >> cordova-ios
> >> > etc), is there anything that prevents us from merging plugman and cli
> >> into
> >> > a single npm package with 2 executables?
> >> >
> >> >
> >> > Examples of code that should be shared include:
> >> > - Common logging and error handling logic (e.g. CordovaError
> exception)
> >> > - Fetching logic (for plugins and platforms)
> >> > - Platform-specific logic (e.g. where the config.xml file lives within
> >> each
> >> > project)
> >> > - Generic utilities like xml-helpers.js (currently copied but slightly
> >> > diverged in the 2 repos)
> >> >
> >> > The first option that comes to mind is to create another repo and
> >> another
> >> > npm package for cordova-lib, but this creates significant overhead:
> >> >  - Version release would get more difficult (see the failed release
> vote
> >> > thread <
> >> https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html
> >> > >from
> >> > last Friday)
> >> >  - In many cases new functionality in plugman or CLI would require
> >> changes
> >> > in 2 or even 3 repos. This is a significant additional barrier for new
> >> > contributors that don't have commit rights - coordinating two
> >> > interdependent pull request is quite a hassle.
> >> >  - Strictly speaking, cordova-lib major version number will have to be
> >> > bumped every time we change some function signatures, which will
> happen
> >> > rather frequently in this case (this point also partially holds true
> if
> >> the
> >> > lib will be part of the plugman repo and npm package).
> >> >
> >> > Based on the points above a single repo and npm package containing
> both
> >> > plugman and cli seems to provide the most benefit.
> >> >
> >> > What do you think?
> >> >
> >>
> >
> >
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

More on this approach:

http://blog.izs.me/post/48281998870/unix-philosophy-and-node-js
https://blog.nodejitsu.com/the-nodejs-philosophy/
http://substack.net/how_I_write_modules


On Fri, Apr 11, 2014 at 10:04 AM, Brian LeRoux <b...@brian.io> wrote:

> I want more repos not less! I'd love for us to break the functionality up
> into a tonne of smaller utility repos. Ideally every module is in a
> discreet git repo, separately versioned, and dependencies are managed with
> npm.
>
>
> On Fri, Apr 11, 2014 at 5:59 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> The overhead of a third repo scares me.  I'm fine with merging into a
>> single repo, but I'll throw a third option into the mix:
>>
>> - Leave the plugman repo, and leave the plugman binary in there, but
>> refactor to make plugman depend on cordova-cli, and forward all
>> functionality to cli implementations.
>>
>> This leaves the APIs entirely untouched and is just an internal refactor.
>>  It would invert the "depends" direction, but I don't think that matters.
>>
>> -Michal
>>
>>
>> On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <ka...@google.com>
>> wrote:
>>
>> > I often find myself making changes that require commits to both plugman
>> and
>> > cli, it's not always clear which repo new code should live in and
>> sharing
>> > utility functions between the two projects is not trivial.
>> >
>> > The idea of "cordova-lib" was mentioned several times on this mailing
>> list.
>> > The lib would contain most of the code from both plugman and cli while
>> the
>> > end tools will be thin wrappers around the lib.
>> >
>> > I wanted to probe how people working on CLI feel about such
>> rearrangement.
>> >
>> > But if we are already in this discussion, now that the heavy platforms
>> > files are distributed separately from cordova-cli (repos like
>> cordova-ios
>> > etc), is there anything that prevents us from merging plugman and cli
>> into
>> > a single npm package with 2 executables?
>> >
>> >
>> > Examples of code that should be shared include:
>> > - Common logging and error handling logic (e.g. CordovaError exception)
>> > - Fetching logic (for plugins and platforms)
>> > - Platform-specific logic (e.g. where the config.xml file lives within
>> each
>> > project)
>> > - Generic utilities like xml-helpers.js (currently copied but slightly
>> > diverged in the 2 repos)
>> >
>> > The first option that comes to mind is to create another repo and
>> another
>> > npm package for cordova-lib, but this creates significant overhead:
>> >  - Version release would get more difficult (see the failed release vote
>> > thread <
>> https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html
>> > >from
>> > last Friday)
>> >  - In many cases new functionality in plugman or CLI would require
>> changes
>> > in 2 or even 3 repos. This is a significant additional barrier for new
>> > contributors that don't have commit rights - coordinating two
>> > interdependent pull request is quite a hassle.
>> >  - Strictly speaking, cordova-lib major version number will have to be
>> > bumped every time we change some function signatures, which will happen
>> > rather frequently in this case (this point also partially holds true if
>> the
>> > lib will be part of the plugman repo and npm package).
>> >
>> > Based on the points above a single repo and npm package containing both
>> > plugman and cli seems to provide the most benefit.
>> >
>> > What do you think?
>> >
>>
>
>

Re: Sharing code between plugman and cordova-cli

[Brian LeRoux <b...@brian.io>]

I want more repos not less! I'd love for us to break the functionality up
into a tonne of smaller utility repos. Ideally every module is in a
discreet git repo, separately versioned, and dependencies are managed with
npm.


On Fri, Apr 11, 2014 at 5:59 AM, Michal Mocny <mm...@chromium.org> wrote:

> The overhead of a third repo scares me.  I'm fine with merging into a
> single repo, but I'll throw a third option into the mix:
>
> - Leave the plugman repo, and leave the plugman binary in there, but
> refactor to make plugman depend on cordova-cli, and forward all
> functionality to cli implementations.
>
> This leaves the APIs entirely untouched and is just an internal refactor.
>  It would invert the "depends" direction, but I don't think that matters.
>
> -Michal
>
>
> On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <ka...@google.com>
> wrote:
>
> > I often find myself making changes that require commits to both plugman
> and
> > cli, it's not always clear which repo new code should live in and sharing
> > utility functions between the two projects is not trivial.
> >
> > The idea of "cordova-lib" was mentioned several times on this mailing
> list.
> > The lib would contain most of the code from both plugman and cli while
> the
> > end tools will be thin wrappers around the lib.
> >
> > I wanted to probe how people working on CLI feel about such
> rearrangement.
> >
> > But if we are already in this discussion, now that the heavy platforms
> > files are distributed separately from cordova-cli (repos like cordova-ios
> > etc), is there anything that prevents us from merging plugman and cli
> into
> > a single npm package with 2 executables?
> >
> >
> > Examples of code that should be shared include:
> > - Common logging and error handling logic (e.g. CordovaError exception)
> > - Fetching logic (for plugins and platforms)
> > - Platform-specific logic (e.g. where the config.xml file lives within
> each
> > project)
> > - Generic utilities like xml-helpers.js (currently copied but slightly
> > diverged in the 2 repos)
> >
> > The first option that comes to mind is to create another repo and another
> > npm package for cordova-lib, but this creates significant overhead:
> >  - Version release would get more difficult (see the failed release vote
> > thread <
> https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html
> > >from
> > last Friday)
> >  - In many cases new functionality in plugman or CLI would require
> changes
> > in 2 or even 3 repos. This is a significant additional barrier for new
> > contributors that don't have commit rights - coordinating two
> > interdependent pull request is quite a hassle.
> >  - Strictly speaking, cordova-lib major version number will have to be
> > bumped every time we change some function signatures, which will happen
> > rather frequently in this case (this point also partially holds true if
> the
> > lib will be part of the plugman repo and npm package).
> >
> > Based on the points above a single repo and npm package containing both
> > plugman and cli seems to provide the most benefit.
> >
> > What do you think?
> >
>

Re: Sharing code between plugman and cordova-cli

[Michal Mocny <mm...@chromium.org>]

The overhead of a third repo scares me.  I'm fine with merging into a
single repo, but I'll throw a third option into the mix:

- Leave the plugman repo, and leave the plugman binary in there, but
refactor to make plugman depend on cordova-cli, and forward all
functionality to cli implementations.

This leaves the APIs entirely untouched and is just an internal refactor.
 It would invert the "depends" direction, but I don't think that matters.

-Michal


On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <ka...@google.com> wrote:

> I often find myself making changes that require commits to both plugman and
> cli, it’s not always clear which repo new code should live in and sharing
> utility functions between the two projects is not trivial.
>
> The idea of “cordova-lib” was mentioned several times on this mailing list.
> The lib would contain most of the code from both plugman and cli while the
> end tools will be thin wrappers around the lib.
>
> I wanted to probe how people working on CLI feel about such rearrangement.
>
> But if we are already in this discussion, now that the heavy platforms
> files are distributed separately from cordova-cli (repos like cordova-ios
> etc), is there anything that prevents us from merging plugman and cli into
> a single npm package with 2 executables?
>
>
> Examples of code that should be shared include:
> - Common logging and error handling logic (e.g. CordovaError exception)
> - Fetching logic (for plugins and platforms)
> - Platform-specific logic (e.g. where the config.xml file lives within each
> project)
> - Generic utilities like xml-helpers.js (currently copied but slightly
> diverged in the 2 repos)
>
> The first option that comes to mind is to create another repo and another
> npm package for cordova-lib, but this creates significant overhead:
>  - Version release would get more difficult (see the failed release vote
> thread <https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html
> >from
> last Friday)
>  - In many cases new functionality in plugman or CLI would require changes
> in 2 or even 3 repos. This is a significant additional barrier for new
> contributors that don’t have commit rights - coordinating two
> interdependent pull request is quite a hassle.
>  - Strictly speaking, cordova-lib major version number will have to be
> bumped every time we change some function signatures, which will happen
> rather frequently in this case (this point also partially holds true if the
> lib will be part of the plugman repo and npm package).
>
> Based on the points above a single repo and npm package containing both
> plugman and cli seems to provide the most benefit.
>
> What do you think?
>