Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.220.179 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CABiQX1XUM_oXZzKpc+xABjbN3mF80MzCamXdcyOm8ceMc4hT7w@mail.gmail.com>
References: 
 <CA+GVa3aiGaX4bSaUn29mmHjofcQQ=q3c42F7BBsTXwGYs8JX4g@mail.gmail.com>
 <D0D44208.6F16C%jsoref@blackberry.com>
 <CA+GVa3bjdUeQotAfP4ZUe_0w40ueXmKht52dCUkyeep6udR6zA@mail.gmail.com>
 <CABiQX1Ui3GBS1X7-jS7PckO_fG0Ok55QfpQ+e5eCDvwGLObTDA@mail.gmail.com>
 <CAEeF2TdwDhBBkhasY-EwbrY_+J+28Nyb7_BZfqGzvEjLY9+qgw@mail.gmail.com>
 <CA+GVa3aprKFx_QE061suubJFnB4u4TrctAMQEh9MdJe01JpNfA@mail.gmail.com>
 <CAMSbhBi0BqKAA3M5nCCwzFfDjWW_6sF-1oSCyxRojqwcbgrAhw@mail.gmail.com>
 <CA+GVa3bLP1SGWwCZTr-E8YZHD=wS2_FuMZFSDzXw5ZmtqwHZZA@mail.gmail.com>
 <CAMSbhBgzXvqSCLPVDSTP8J6N6H9ZFu=X3ML2gAn-B9_T3nFX_Q@mail.gmail.com>
 <CABiQX1XUM_oXZzKpc+xABjbN3mF80MzCamXdcyOm8ceMc4hT7w@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Fri, 9 Jan 2015 11:19:00 -0500
Message-ID: 
 <CAEeF2TetSVtJNkmm=fAQU745BCczd7+okBEBN5eXiOwFpS9AjA@mail.gmail.com>
Subject: Re: MobileSpec for testing cordova-lib@rc
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b342d94dec2fd050c3a8457

--047d7b342d94dec2fd050c3a8457
Content-Type: text/plain; charset=UTF-8

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 <agrieve@chromium.org> wrote:

> On Thu, Jan 8, 2015 at 8:39 PM, Steven Gill <stevengill97@gmail.com>
> 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 <kamrik@google.com>
> 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 <stevengill97@gmail.com>
> > > 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 <kamrik@google.com>
> > > wrote:
> > > >
> > > > > On Thu, Jan 8, 2015 at 3:47 PM, Michal Mocny <mmocny@chromium.org>
> > > > 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
> > > > >
> > > >
> > >
> >
>

--047d7b342d94dec2fd050c3a8457--