Just checked out peer-dependencies. Looks like the way to move forward with handling our dependency issues.
Right now, plugman publish creates a package.json file by grabbing info from plugin.xml. Once published, plugman will automatically delete the package.json file. I suggest we stop deleting the package.json file and actually commit it to all plugin repos. What is wrong with uploading the plugins with their current ids as package names for npm? (ex. org.apache.cordova.device). Then you could just add org.apache.cordova.device to your package.json file. It is just for distinguishing which modules are plugins at plugin add time? We could do that with some sort of check looking for a plugin.xml in the directory or maybe adding a cordova plugin keyword to the package.json files. I just think uploading them under a different name to npm will get confusing. But having a standard that others use as well doesn't sound like a bad idea (grunt does it ex grunt-contrib-clean). Worth discussing. Ultimately, I'd like to see us support both workflows (CLI vs JS API). - We would publish plugins to cordova registry & npm. - Plugman install would pull down from one (eventually default to npm and then cordova registry as backup if not found on npm or if version is lower) - Eventually close down the cordova plugins registry, move plugins over to npm only. Plugins.cordova.io would just search npm based on a cordova plugins keyword (like http://gruntjs.com/plugins) With the JS API workflow, users can write code in es6 and use a transpiler (like https://www.npmjs.com/package/6to5) to convert that code to es5 and that is their www code. Then we run the cordova JS API to create a project out of that. Have the transpiling + creating cordova project as a build step in our package.json (or grunt/gulp). I guess this technique can be used to use other modules that support browserify and run that as a build step before building the cordova project. Fun stuff! On Thu, Jan 8, 2015 at 3:36 PM, Mark Koudritsky <[email protected]> wrote: > +1 for publishing plugins to npm > > We will need to come up with a good naming convention so that translating > from plugin id to npm package name would be trivial. Preferably with some > stable prefix (like cordova_plugin_) so that it would be easy to > distinguish plugins if they are listed with other dependencies in > package.json > > Another problem to solve are the dependencies _between_ plugins. We don't > want nested dirs like node_modules/pluginX/node_modules/pluginY or multiple > version of the same plugin (like it happens for regular npm deps). Maybe > npm peer dependencies could be used to solve this > http://blog.nodejs.org/2013/02/07/peer-dependencies/ > > For experimenting with this, there is no need to modify cordova-lib. We > just need to publish some experimental plugins to npm registry, let npm > download them during npm install and then add ./node_modules to searchpath. > I tried this with platforms in > https://github.com/kamrik/CordovaGulpTemplate > > > On Thu, Jan 8, 2015 at 6:02 PM, Steven Gill <[email protected]> > wrote: > > > This is rad! Definitely a great example showing the JS API. > > > > I am thinking about also starting to publish our plugins to npm and add a > > flag to plugman install to fetch from npm instead of cordova plugins > > registry. Thoughts? > > > > On Thu, Jan 8, 2015 at 1:09 PM, Mark Koudritsky <[email protected]> > wrote: > > > > > On Thu, Jan 8, 2015 at 3:47 PM, Michal Mocny <[email protected]> > > wrote: > > > > > > > If we add node_modules to search path, will we be able to adjust > which > > > > versions of platforms/plugins it uses just by modifying package.json? > > > > > > > > > > > Since platforms can be added by path. You can replace > > > platforms = ['android'] > > > with > > > platforms = ['/path/to/local/cordova-android'] // Should work for > using > > > e.g. cordova-android 4.x > > > or > > > platforms = ['../node_modules/cordova-android'] > > > > > > > > > > Not sure if platforms use search path, or just plugins? Also not > sure > > if > > > > we can install plugins from our registry using npm proper, but you > can > > > use > > > > the git repos as a workaround if not. > > > > > > > > > > For plugins it's more tricky (other npm repo, different dependency > > model). > > > Some options are: > > > - use private cordova subsection in package.json and store plugin info > > > including versions there in whatever format we want > > > > > >
