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