Why rename plugins now? I think the plugin.xml can remain the same even with the move to npm. Its just the npm package name that would be new.
I think we have enough ongoing ideas (see also Gorkems work), that we should put together a doc / have a hangout before making any significant changes. -Michal On Fri, Jan 9, 2015 at 5:01 PM, Steven Gill <[email protected]> wrote: > In terms of discoverability, It seems like npm is going to make > ecosystem/collection searches a first class thing [1] [2] > "An early discussion of collections > <https://github.com/npm/newww/issues/313> is taking place on GitHub > issues, > and npm ecosystems <http://browserifysearch.org/> are starting to pop up > in > userspace. We'll be freed up in the coming months to focus on making > collections and ecosystems a first-class part of the npm experience, but > first we must attend to more pressing matters: private modules." > > So sites like http://browserifysearch.org/ won't be necessary I believe. > This should solve the discoverability problem. Browserify compatible > modules aren't prefixed. But then again, those modules are also stand alone > modules where cordova plugins can only be used with cordova projects. > > I am just worried that our users will get confused with the name change. If > installing via cli, use org.apache.cordova.device. If installing via npm, > use cordova-plugin-device. I guess this wouldn't be a big deal if the > prefix was dumb (ex cordova-plugin-device, cordova-plugin- + 4th item of > reverse domain id). During plugin installation, we could convert > org.apache.cordova.device to cordova-plugin-device to pull from npm for CLI > workflow. In JSAPI workflow, users can do npm install --save > cordova-plugin-device > > FTR, I'm open to renaming. If we are going to do it, now is obviously the > time. Just want to make sure it is painless as possible for users and > plugin developers. > > > [1] http://blog.npmjs.org/post/104856015780/npm-has-a-new-website > [2] https://github.com/npm/newww/issues/313 > > On Fri, Jan 9, 2015 at 10:58 AM, Mark Koudritsky <[email protected]> > wrote: > > > Having two different names for the same plugin would be pretty annoying > (if > > it's not something trivial like nameB = prefix + nameA). If > > reverse-domain-style > > IDs are not really necessary, I would be glad to see them eventually > > replaced > > with shorter and more memorable names. > > > > For CLI based projects, auto adding from node_modules sounds good. > > > > On Fri, Jan 9, 2015 at 11:19 AM, Michal Mocny <[email protected]> > wrote: > > > > > So, `npm install` will look at the project root package.json and > install > > > all "dependencies" in the npm package format. `cordova plugin add` > will > > > take the plugin_ID and look in your plugin_search_path's for plugins > with > > > that ID, and fallback to fetching from our plugin registry if it does > not > > > find one. > > > > > > So, I think there is no conflict in naming the npm packages in a > > different, > > > cleaner style (i.e. cordova-plugin-file-transfer). That is because to > > > install a plugin from npm you would have to do two separate steps > > anyways: > > > > > > > npm install --save cordova-plugin-file-transfer # or just npm > install > > > if its already in your package.json > > > > cordova plugin add org.apache.cordova.file-transfer # assuming > > > node_modules is in plugin_search_path by default > > > > > > If we want to merge these two steps into one (good idea), there are > > > options: > > > > > > 1. Turn our plugin registry into a plugin_ID -> npm-package-name > lookup, > > > and support `cordova plugin add --npm plugin_ID` > > > 2. Always auto-add all plugins from node_modules during prepare, and > > ditch > > > the `cordova plugin add` step altogether. If you want to install local > > > plugins for development, use npm link. > > > 3. Other options? > > > > > > -Michal > > > > > > On Fri, Jan 9, 2015 at 10:32 AM, Andrew Grieve <[email protected]> > > > wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
