Interesting points about plugins. IMO It would be a good amount of work to move plugins over to npm. Definitely worth it for us to continue discussing the feasibility of it.
As for platforms, most people seem to be in agreement about moving them over to npm and setting them as dependencies for the cli. Is this something we should start moving forward with? On Wed, Mar 19, 2014 at 5:45 PM, Carlos Santana <[email protected]>wrote: > 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]> >
