cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: MobileSpec for testing cordova-lib@rc
Date Mon, 12 Jan 2015 12:57:46 GMT
Why rename plugins now?  I think the plugin.xml can remain the same even
with the move to npm.  Its just the npm package name that would be new.

I think we have enough ongoing ideas (see also Gorkems work), that we
should put together a doc / have a hangout before making any significant
changes.

-Michal

On Fri, Jan 9, 2015 at 5:01 PM, Steven Gill <stevengill97@gmail.com> wrote:

> 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 <kamrik@google.com>
> 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 <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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message