cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Consolidating the Distribution of Platforms & Plugins
Date Tue, 18 Mar 2014 21:59:15 GMT
I don't see how we can rely on npm's dependency system (or npm install) for
Cordova because npm dependencies consist of a tree of isolated
node_modules/ whereas cordova has to share code amongst multiple plugins
(different build system than npm/node). We could use `npm install` for
auto-fetching but we might fetch the same plugin multiple times if other
plugins depend on it. The meat of dependency management is not in the
fetching part.

We actually looked into leveraging npm for everything but it turned out to
be not possible. Cordova projects are just not exactly like node projects.

Also from a user/developer perspective it's a lot nicer to have one place
to look for cordova plugins rather than ~65 000 npm packages of which most
are not even Cordova related. Platforms don't matter because
users/developers are not supposed to be aware of their existence.

my 0.02

-a


On Sat, Mar 15, 2014 at 3:54 PM, Carlos Santana <csantana23@gmail.com>wrote:

> Jonathan
>    Today we don't support that scenario with cordova cli, if a plugin
> supports multiple platforms you can't block "cordova plugin add" from
> installing to all platforms that it supports.
> Maybe a new enhancement request?
>
> My intention with having the dependencies info was solely to get the all
> the dependency files download via npm, either via user running "npm
> install" or cordova using user's global npm to get the files down to the
> system.
> It was not the intention of "dependencies" to drive the composition of the
> App. it can be use but I think more control using like an new property
> "cordova" in package.json, or pacakge.json may not have this info and just
> deal with dowloading the correct versions of platform and plugins, to then
> be use by "cordova lib" to do it's thing.
> This also gives flexibility to drive cordova how ever  the user wants even
> with npm "scripts" lifecycles with a "postinstall"
>
> Yes I agree the devils is in the details, and a lot of space for
> exploration going forward.
>
> --Carlos
>
>
>
> On Sat, Mar 15, 2014 at 9:11 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Fri Mar 14 11:36 PM, Carlos Santana wrote:
> > > I have being thinking on this sort of problem also.
> > >
> > > I think using npm to store none node code is perfectly fine use case.
> > >
> > > I vote to leverage npm as the building block and then build cordova
> > functions on
> > > top of it.
> > >
> >
> > +1 where possible like caching
> >
> > >
> > > "dependencies": {
> > >    "org.apache.cordova.platform.ios": ">=3.4.0",
> > >    "org.cordova.platform.android": ">=3.3.0",
> > >    "org.apache.cordova.device": "~0.2.8",
> > >    "cordova-cli": "~3.4.0"
> > > },
> >
> > That's a bit of an oversimplification, you may not want the same plugin
> on
> > android & ios.
> >
> > -1 on dependencies through npm, +1 with Braden for cordova lib that
> > handles the dependency fetching.
> >
> > Devil's in the details so +1 for experimenting though
> >
> >
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

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