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