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