cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Consolidating the Distribution of Platforms & Plugins
Date Wed, 19 Mar 2014 18:20:50 GMT
Agree we don't want to use node_modules, nor the "dependency" field.

I do think we should use it's fetching logic via "npm cache add" though,
and then copy the downloaded plugin from the npm cache dir to the project.


On Tue, Mar 18, 2014 at 2:59 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> 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