I agree that npm would not be able to resolved the dependencies.
That's something that cordova would need to resolved. if plugin A 1.0
depends on plugin B version 1.0, and plugin C 1.0 depends on plugin B
version 2.0
Codova Tool will be the one to determined the final flat set of plugins and
their version.
if plugin depends on other plugins, I think that's still belongs in
plugin.xml
But cordova can construct the package.json as the user keeps adding plugins
Then package.json will have the final flat list.
i.e.
(peerDependencies || dependencies || bundleDependencies" {
A : "^1.0",
B: "^2.0",
C:"1.0"
}
then package.json can be shared and another developer can just replicate
app. I guess the same can be said if we create a cordova.json with same info
As far on searching I don't mind plugins showing up in npmjs.org
That doesn't stop Cordova Project of having a useful website
plugins.cordova.io to search, rate, discover, only Cordova packages/plugins.
Other people doing this already, packages in npm db and website listing
their related plugins for searching and listing, etc..:
http://yeoman.io/community-generators.html
http://gruntjs.com/plugins
http://gulpjs.com/plugins/
http://bower.io/search/
my $0.02
On Wed, Mar 19, 2014 at 2:20 PM, Andrew Grieve <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]
> > >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 <
> > > [email protected]> 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
> > > <[email protected]>
> > >
> >
>
--
Carlos Santana
<[email protected]>
