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) > 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 >
