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 kamrik@google.com designates
 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEeF2TetSVtJNkmm=fAQU745BCczd7+okBEBN5eXiOwFpS9AjA@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>
 <CAEeF2TetSVtJNkmm=fAQU745BCczd7+okBEBN5eXiOwFpS9AjA@mail.gmail.com>
From: Mark Koudritsky <kamrik@google.com>
Date: Fri, 9 Jan 2015 13:58:27 -0500
Message-ID: 
 <CA+GVa3a4_tztMyve_TVVWJC54aH0Nyq=d1zAWPmw=M3rFpbqEg@mail.gmail.com>
Subject: Re: MobileSpec for testing cordova-lib@rc
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=001a113a92bc1adb60050c3cbf05

--001a113a92bc1adb60050c3cbf05
Content-Type: text/plain; charset=UTF-8

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 <mmocny@chromium.org> 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 <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
> > > > > >
> > > > >
> > > >
> > >
> >
>

--001a113a92bc1adb60050c3cbf05--