On Mon, Aug 18, 2014 at 5:58 PM, Brian LeRoux <b...@brian.io> wrote: > We don't have to make plugins a package.json thing…we could do that latter. > If we do choose to use package.json highly likely we'll need to reserve a > key for our 'namespace'. Perhaps "cordova". That key could have whatever we > want in it (such as mapping our current config.xml properties/values). > > > On Mon, Aug 18, 2014 at 2:16 PM, Mark Koudritsky <kam...@google.com> > wrote: > > > In order to keep the plugins as project deps in package.json we need to > > sort out some details of treating plugins as npm packages first: > > > > 1) Plugins don't currently have package.json files, and list their deps > in > > plugin.xml. > > 2) Are we ok with loosing the possibility of specifying platform specific > > dependencies? (e.g. plugin A might depend on plugin B for iOS and on > > nothing for Android) > Might need to do something custom for dependencies of plugins, since the nested-dependency concept that node uses doesn't work for plugins (can't have multiple versions of the same plugin).
> > 3) Simply listing deps inside the newly created package.json in plugins > > will create a possibly deep tree of plugin/node_modules/plugin folders > with > > possible duplicates. Npm's peer dependencies > > <http://blog.nodejs.org/2013/02/07/peer-dependencies/> might be the > right > > solution, but I haven't looked at it yet. > > > > > > I agree that Cordova is a build system to a very large extent. But then > it > > makes more sense to treat it as a tool to be used by other build systems > > rather than re-invent all the wheels on our own. > > > > Recently I tried building a cordova project with Gulp without using the > > CLI, it works great. > > https://github.com/kamrik/CordovaGulpTemplate > > > > Some time ago Carlos did a similar thing with Grunt: > > https://www.npmjs.org/package/grunt-cordovacli > > >
