cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Victor Sosa <sosah.vic...@gmail.com>
Subject Re: Plugins to NPM (Phase 1)
Date Thu, 26 Mar 2015 19:05:32 GMT
With regarding this Plugins to NPM topic...

This is a change that will impact to IDEs who rely on
http://registry.plugins.io to show available plugins to users. Even though
there will be a window for this change, CPR will have a 6-months window (at
least this is my understanding) to let plugin developers to migrate their
plugins to NPM and also let users to use in the old way (I mean the current
plugin IDs), there will be the point that this will be unsupported by
Cordova, hence support in IDEs will break.

I've been doing a little research and collecting some information and here
the summary of my findings:
1. The plugins will be hosted in http://registry.npmjs.org/
2. All NPM documents can be listed by querying the server with the
following URL: http://registry.npmjs.org/-/all
3. If you are interested on the Cordova plugins only (as will be the case),
use the keyword "ecosystem:cordova" to filter out the contents in this
list. Here is an error prone point, if the plugin doesn't have this keyword
it will never be found making hard to developers to know it in fact exists
(this is one of the major plus sides on CPR imho).
4. The only way to get such filtered list is to fetching all documents in
NPMJS registry and then do the filter locally using the keyword
"ecosystem:cordova", i.e. there is no way to get a filtered list directly
from the registry (I looked at NPM code and this is what they do. See in
NPM module, <cordova_install_dir>/node_modules/npm/lib/search.js file,
around line 60 "getFilteredData" function).

With those steps, I'm able to retrieve the list of plugins that follow the
"ecosystem:cordova" contract that was proposed before in a headless way,
i.e. no web browser, just a small script.

If any of you have suggestions on how better do this Cordova plugins
discovery on NPMJS, please let me know.


2015-03-25 15:36 GMT-06:00 Horn, Julian C <julian.c.horn@intel.com>:

> I'd like to add some more questions to what Leo asked.
>
> Can anyone explain how the hundreds of plugins that are published in git
> repos are supposed to transition to CLI 5 (and beyond)?  It seems like the
> answer is that they don't change anything.  What if they want to (or
> already do) publish via the registry?  It seems like you can win if you
> keep the id unchanged and add yourself to the mapping table.  But if that's
> true, then why are we renaming the core plugins?
>
> I don't think repo-resident plugins need to update any <dependency> tags
> that refer to core plugins.  That is, you can continue to ask for
> "org.apache.cordova.file".  If you use CLI 5, then the rename logic will
> get you the corresponding plugin from npm.  Or is there some reason why you
> will eventually have to change your <dependency> tags to use the new
> names.  Of course you better not change a <dependency> tag in your
> repo-resident plugin before October 1, because that will break projects
> that use your plugin but aren't yet using CLI 5.
>
> I haven't been able to come up with any strategy for changing the id of a
> repo-resident plugin without great pain.  It's basically equivalent to
> discontinuing your plugin and creating a new one in its place.  So it seems
> to me that if I have any users I would probably want to stick with my
> existing id and repo URL, even if it meant that I couldn't publish my
> plugin in npm format.  Is that a viable strategy, or is there a long term
> plan that EVERY plugin must eventually publish via npm?
>
> One final question.  Suppose I have a CLI 4.x project and I want to
> transition to CLI 5.  Do I have to start over at "cordova create project"?
>
>     Julian
>
> -----Original Message-----
> From: Treggiari, Leo [mailto:leo.treggiari@intel.com]
> Sent: Wednesday, March 25, 2015 3:53 PM
> To: dev@cordova.apache.org
> Subject: RE: Plugins to NPM (Phase 1)
>
> Thanks for the information Steve.  That helps with our planning.  I have a
> couple of follow-ups.
>
> > We don't necessarily have to do a major bump for the CLI. We could
> > easily save the major jump until we switch npm fetching as default
> > (approx July 1)
>
> Re: the major bump.  This seems like a "delayed" breaking change.  That
> is, when CPR is removed, all prior CLI releases will be "crippled" to a
> significant degree since no <pluginid> reference will be able to be
> resolved.
>
> Re: ~July 1:  Would you verify my understanding?  For a <pluginid>
> reference which is not in the mapping table, from ~Apr to ~July 1, CPR will
> be tried first and if that fails then npm.  From ~July 1 to ~Oct 1, npm
> will be tried first and if that fails then the CPR.  After ~Oct 1, only npm.
>
> Thanks,
> Leo
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengill97@gmail.com]
> Sent: Wednesday, March 25, 2015 11:13 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins to NPM (Phase 1)
>
> Thanks for answering tony. More comments below.
>
> On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony <tony.homer@intel.com>
> wrote:
>
> > I¹ll try to answer some of Leo¹s questions, but it would be great if
> > someone else (Steve?) could comment.
> >
> > First, though, I¹ll ask a question of my own.
> > Is there a doc or JIRA task for tracking all of the activity related
> > to moving plugins to NPM?
> > There was the Google Doc that was created last hangout for tracking
> > the proposal, but it doesn¹t list JIRAs and hasn¹t been updated since
> > January.
> > I found CB-8529, CB-8538 and CB-8551 but they are not linked to a
> > master task JIRA.
> > This is not a jab at Steve at all, I¹m just wondering if there is or
> > should be a reference for this set of tasks (other than staying caught
> > up with reading the list)?
> >
>
> Good point. I have created a master issue at
> https://issues.apache.org/jira/browse/CB-8743
>
>
> > On to Leo¹s questions-
> >
> > Will the release be named Cordova 5.0?
> > Unknown at this time?  It seems like this will require a co-ordinated
> > release of CLI, Tools and Plugins, with major version bumps for all.
> >
>
> We haven't discussed this yet. We don't necessarily have to do a major bump
> for the CLI. We could easily save the major jump until we switch npm
> fetching as default (approx July 1)
>
> >
> > Will it trigger a major revision bump?
> > Yes.
> >
>
> For plugins, yes. All of the core plugins will be getting a major version
> bump shortly.
>
> >
> > What is the current estimate for the release?
> >
> > I would say ³when it¹s done² but it would be great to get a more specific
> > answer.
> > I¹m not sure if that¹s possible?
> >
>
> Aiming for April 1st.
>
> >
> > If release of Phase 1 occurs on April 1 does this mean that the CPR
> > becomes read-only on July 1 and is
> > deleted on Oct 1?
>
> I think the real driver was that there is an external hosting issue with
> > CPR after Oct. 1.
> > The 3 month period was adopted so provide a transition window, but there
> > is a hard stop on or around Oct. 1.
> > Steve had mentioned this somewhere but I can¹t find it now.
> >
>
> - CPR becomes read-only July 1st (if we release April 1st)
> - Tools fetch from NPM by default on July 1st (currently checks CPR first,
> npm as fallback)
> - We will try to keep CPR open as read-only for as long as possible.
> Nodejitsu people told us they could give us the 6 months but we will see if
> we can stretch it. A day will come when we will have to shut down CPR
> though.
>
> >
> > -  On Oct 1, all previous releases of Cordova CLI (< 5.0) will
> immediately
> > be "broken"?
>
>
> > Yes, that is my understanding, although in reading back over the
> > discussion I don¹t see where it is explicitly addressed.
> > I was assuming that this is intended in part as a forcing function.
> >
>
> Yes. We could look into setting up some redirect service to keep old
> versions working. But for now, we are saying users will have to upgrade.
>
> >
> > Tony
> >
> >
> > On 3/20/15, 11:05 AM, "Treggiari, Leo" <leo.treggiari@intel.com> wrote:
> >
> > >I have a few questions about Phase 1 (and beyond) as I plan how to
> > >migrate the Intel XDK and existing user projects through this change.
> > >
> > >-  Will the release be named Cordova 5.0?  This seems worthy of a major
> > >bump for the CLI in addition to the plugins.
> > >
> > >-  What is the current estimate for the release?  I assume soon.
> > >
> > >-  For the purpose of my questions, I'll assume the release occurs on
> > >April 1.  This means that the CPR becomes read-only on July 1 and is
> > >deleted on Oct 1?
> > >
> > >-  On Oct 1, all previous releases of Cordova CLI (< 5.0) will
> > >immediately be "broken"?  That is, they cannot add new plugins, they
> > >cannot "restore" plugins, etc.  "Local" and "git repo" plugins continue
> > >to work, but my assumption is that the vast majority of plugins come
> from
> > >CPR (soon to be npm).
> > >
> > >Thanks,
> > >Leo
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@gmail.com]
> > >Sent: Monday, March 09, 2015 5:20 PM
> > >To: dev@cordova.apache.org
> > >Cc: sosah.victor@gmail.com
> > >Subject: Update: Plugins to NPM (Phase 1)
> > >
> > >Our master branch has plugin fetching from npm set as the fallback now.
> It
> > >will go directly to npm if the plugin-id entered isn't reverse domain
> name
> > >style. Cordova-lib also warns users to use the package-name instead of
> > >plugin-id when adding plugins that we have renamed and are in
> > >https://github.com/stevengill/cordova-registry-mapper
> > >
> > >Plugins TODO:
> > >
> > >- README: Move doc/en/index.md into README.md. Delete doc/en/index.md.
> > Add
> > >links in README.md that point to github page of translated docs for
> > >plugin.
> > >(ex.
> > >
> >
> https://github.com/apache/cordova-plugin-device/blob/master/doc/es/index.m
> > >d).
> > >I'd love to hear from someone (Victor?) working on docs translations
> about
> > >how this change will impact them.
> > >
> > >- Rename plugin-ids to new plugin names in plugin.xml. Anything we
> should
> > >be aware of before we do this? (Ex. rename org.apache.cordova.device to
> > >cordova-plugin-device in plugin.xml)
> > >
> > >- Add peer dependencies to plugins that depend on other plugins (file,
> > >media-capture, etc)
> > >
> > >- Paramedic support for every plugin
> > >
> > >- Major version bump for all core plugins
> > >
> > >- Update plugins release process to use package.json version as main
> > >version and have it update plugin.xml's version. Will do this when we do
> > >next release
> > >
> > >Migration TODO:
> > >
> > >- Create blog post talking about migration to npm for community
> > >
> > >- include how we are renaming, suggest they do so if they want to. Will
> > >suggest they follow the pattern cordova-plugin-*
> > >
> > >- mention https://github.com/stevengill/cordova-registry-mapper for
> > >warning
> > >purposes
> > >- include potential lifespan of CPR (publishing and read only)
> > >- Discuss plugman createpackage.json command
> > >- Discuss keyword: 'ecosystem:cordova'
> > >
> > >
> > >Thoughts? Missing anything?
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> -Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>


-- 
Victor Adrian Sosa Herrera
IBM Software Engineer
Guadalajara, Jalisco

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