On Thu, Jan 8, 2015 at 8:39 PM, Steven Gill <[email protected]> wrote:
> 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. > Sounds good. This way authors can add whatever extra metadata they want. > > 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. > I think a prefix will just help for discoverability. E.g. everything that starts with cordova-plugin- is a cordova plugin. Is it still important to use reverse-domain-style IDs? cordova-plugin-org.apache.cordova.file-transfer? Seems like that's getting a bit verbose, and with the state of our current "core" apis, I'm not sure we want to might them as promoted / distinguishable as other random ones. So maybe cordova-plugin-file-transfer is just fine, and if someone else write cordova-plugin-file-upload, then that's great! > > Ultimately, I'd like to see us support both workflows (CLI vs JS API). > - We would publish plugins to cordova registry & npm. > I believe npm support for multiple registries within one package.json is coming, but at the same time, I don't think any of us are that interesting in maintaining our own database... So, +1 for migrating to npm's database. > - 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) > +1 > > 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 > > > > > > > > > >
