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 <mmo...@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
<csantan...@gmail.com>

Reply via email to