cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Schedule for npm transition
Date Mon, 23 Feb 2015 19:42:32 GMT
On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill <stevengill97@gmail.com> wrote:

> +1 to giving plugins major version bump
> +1 to publishing old versions to npm
>
> Short term we can keep dependency tag using plugin ids. Wouldn't it make
> more sense long term to move those dependencies into package.json file of
> each plugin?
>

Probably peerDependencies not dependencies.  I forgot about that.. Indeed
that was the plan.

I think one current benefit of <dependency> tag over package.json is that
the latter only guarantees that the plugins are downloaded, while the
former guarantees that they are installed.  We could update our tools to do
an install time check for a package.json and then scan the locally
installed packages which are listed in its peerDependencies to see if any
are cordova plugins and install those automatically, but I'm not quite sure
thats the right voodoo..

Anyway, assuming we can come up with a sensible plan, I would rather do it
all at once with the upcoming Major version bump.



>
> I am going to begin the process of adding package.json to all of our
> plugins today and will look into publishing older versions to npm.


> Third-party plugins can either keep their package-id as package-name or
> rename. It will be up to them. If they keep it, no need to send a PR to
> mapper module. If they decide on a new package-name, it is probably in
> their best interest to send a PR.


Sounds good, though I'm hoping to provide guidance that renames are better
by doing it for core plugins.  The need for the mapper is probably a bit of
an exaggeration anyway.  Once CPR goes deprecated, we should start warning
that plugins should be fetched from npm.  Users will then search for the
name of the npm package and the plugin author can rename freely by just
documenting accordingly.  Once the CPR goes down, this will be even more
true.

(Additionally, authors can publish a CPR plugin before CPR goes down that
has an install hook which says "This plugin has moved to npm under the
name..".  I'm less and less convinced the mapper is needed at all..)




>
>
>
>
> On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana <csantana23@gmail.com>
> wrote:
>
> > Lets consider to take this time and make our plugins 1.0.0 and start
> > following semver 2.0 more strict. The community is starting to accept
> that
> > is ok if the major number is not zero, and a number means something that
> > can be use in production.
> > I understand that people might have their own opinion on what is a MAJOR,
> > meaning an API brake when the plugin is running on the device and the API
> > of the javascript API to the plugin.
> > But I want to consider how a plugin is manage in terms of tooling,
> > declaring and resolving dependencies, plugin.xml schema,
> > browersify/bootstrapjs,  we could say that this consider an API for the
> > plugin.
> > Another point is if the plugin are going to change in terms how they are
> > manage, we can take an opportunity to take the developers attention with
> > the major version number change to easy distinguish that there something
> > new going with plugins since 1.0.0 and up.
> >
> > On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz <clantz@microsoft.com>
> wrote:
> >
> > > I think the incident over the weekend pointed out that people are in
> fact
> > > pinning versions in plugin dependencies to avoid unexpected regressions
> > or
> > > in apps due to things like security reviews.  (Ex: Each version of a
> > piece
> > > of software that is published inside an app needs to go through a legal
> > > review at some companies.)  So, I think it will be critical that people
> > can
> > > get back to older versions of plugins beyond the 3 + 6 = 9 month CPR
> > > window.  Big time +1 to back publishing versions npm for that reason
> > unless
> > > we intend to keep the CPR around for a long time.  We also will want to
> > > tell plugin authors that they will want to do the same.  (Note that I'm
> > > less worried about IDEs than I am app and plugin authors here.)
> > >
> > >
> > >
> > > What we're talking about so far has been around changing the behavior
> of
> > > cordova-lib over this period.  A few questions assuming we go with
> > having a
> > > mapper module:
> > >
> > >
> > >
> > > 1.      During and after the transition period, should we recommend
> that
> > > 3rd party plugin authors contribute their IDs to the mapper module to
> > > maintain compat as the CPR shuts down if they want/need to publish to
> npm
> > > with a different name? Is there a process we want to setup to make this
> > > easy?
> > >
> > > 2.      What about apps using old versions of Cordova that pre-date npm
> > > support being present? Given it sounds like Nodejitsu will help with
> any
> > > migration needed, is there an urgency to shut down the CPR itself
> > > (regardless of what cordova-lib itself does) in this time window? Or
> are
> > we
> > > simply telling people they have to upgrade to install any new plugins?
> > >
> > >
> > >
> > > -Chuck
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> > > Mocny
> > > Sent: Tuesday, February 17, 2015 9:32 AM
> > > To: dev
> > > Subject: Re: Schedule for npm transition
> > >
> > >
> > >
> > > FYI since its perhaps relevant to npm transition (from npm weekly
> notes):
> > >
> > >
> > >
> > > "We will also be changing the behavior of peerDependencies in npm@3.
> We
> > > won't be automatically downloading the peer dependency anymore.
> Instead,
> > > we'll warn you if the peer dependency isn't already installed. This
> > > requires you to resolve peerDependency conflicts yourself, manually,
> but
> > in
> > > the long run this should make it less likely that you'll end up in a
> > tricky
> > > spot with your packages' dependencies."
> > >
> > >
> > >
> > > -Michal
> > >
> > >
> > >
> > > On Tue, Feb 17, 2015 at 12:13 PM, Andrew Grieve <agrieve@chromium.org
> > > <mailto:agrieve@chromium.org>>
> > >
> > > wrote:
> > >
> > >
> > >
> > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmocny@chromium.org
> > > <mailto:mmocny@chromium.org>>
> > >
> > > > wrote:
> > >
> > > >
> > >
> > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve
> > >
> > > > > <agrieve@chromium.org<mailto:agrieve@chromium.org>>
> > >
> > > > > wrote:
> > >
> > > > >
> > >
> > > > > > Sorry to be dragging this out, but I think it's important that
> the
> > >
> > > > > > plan here is crystal clear.
> > >
> > > > > >
> > >
> > > > > > On Wed, Feb 11, 2015 at 4:56 PM, Michal Mocny
> > >
> > > > > > <mmocny@chromium.org<mailto:mmocny@chromium.org>>
> > >
> > > > > wrote:
> > >
> > > > > >
> > >
> > > > > > > I would agree that we should change plugin ID as well as
> package
> > >
> > > > name,
> > >
> > > > > > but
> > >
> > > > > > > I don't think that affects the results.
> > >
> > > > > > >
> > >
> > > > > > > All 3 of those use cases you mentioned I think are addressed
> > >
> > > > > > equivalently.
> > >
> > > > > > > Whether the plugin is added as a dependency, with save/restore,
> > >
> > > > > > > or explicitly from the command line, cordova-lib would
first
> > >
> > > > > > > check if
> > >
> > > > > there
> > >
> > > > > > is
> > >
> > > > > > > a mapping from old ID -> new package name, or use what's
given
> > >
> > > > > verbatim.
> > >
> > > > > > > So the only concern is with third party plugin authors
who
> chose
> > >
> > > > > > > to
> > >
> > > > > > rename
> > >
> > > > > > > plugins, and already have dependants, and don't register
a
> > >
> > > > > > > mapping
> > >
> > > > with
> > >
> > > > > > us.
> > >
> > > > > > >
> > >
> > > > > >
> > >
> > > > > > There is a runtime dependency on plugin ID. It's used when
> > >
> > > > > > require()ing other JS modules, and on Android it's used to access
> > >
> > > > > > the plugin's
> > >
> > > > native
> > >
> > > > > > side (pluginManager.getPlugin("ID")).
> > >
> > > > > >
> > >
> > > > > > We could have a mapper that knows that I type "plugin add "",
to
> > >
> > > > > > fetch "cordova-plugin-file", but if we also change the plugin
ID,
> > >
> > > > > > then we'll
> > >
> > > > > get
> > >
> > > > > > runtime problems. So... if we have a mapper, then no changing
> > >
> > > > > > plugin
> > >
> > > > IDs.
> > >
> > > > > > Correct?
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > I agree at first, but after sleeping on it, perhaps this is not
> > >
> > > > necessarily
> > >
> > > > > true.  Perhaps changing plugin ID could just be a semver breaking
> > > change?
> > >
> > > > > Then, even if it was installed using old plugin-id and the mapper
> > >
> > > > > mapped
> > >
> > > > to
> > >
> > > > > the npm package-name, any plugin compatible with this MAJOR version
> > >
> > > > > of
> > >
> > > > the
> > >
> > > > > plugin would know to use the new plugin id.
> > >
> > > > >
> > >
> > > > That'd probably work. In practice I haven't seen plugins pin versions
> > >
> > > > within <dependency>, but they probably should.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > >
> > >
> > > > > For old versions of the plugin published to npm, we do have to
> leave
> > >
> > > > > the plugin id as-is.
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > > Okay, so we don't change the plugin ID, just the package name.
> > >
> > > > > > - When people use <dependency>, they should still use
plugin ID
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > Nit: why?  <dependency> (and config.xml <plugin>) should
use the
> > >
> > > > > same target as "cordova plugin add", which at this point should
> > >
> > > > > change to package-name.  If we do leave plugin-id different from
> > >
> > > > > package-name, it should only be used internally by plugin authors
> > >
> > > > > who depend on other plugins.
> > >
> > > > >
> > >
> > > >
> > >
> > > > "plugin add" can take git URLs, local directory paths. <dependency
> > >
> > > > id="" /> is pretty clear that it's an ID, and in this form it doesn't
> > >
> > > > specify where to get the plugin from
> > >
> > > >
> > >
> > > > The logic for dependency in plugman is to:
> > >
> > > > 1. Fetch it  (e.g. use search paths, or find-by-id from the
> registry).
> > >
> > > > 2. Validate that the plugin.xml we fetched matches the ID from
> > >
> > > > <dependency> 3. Install it
> > >
> > > >
> > >
> > > > I don't think we can do the validation step if we allow package-name
> > >
> > > > within <dependency>. Plus, except for core plugins that have a
> mapper,
> > >
> > > > you couldn't do the search-path logic correctly without the plugin
> ID.
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > > - If they "cordova plugin add", we'll allow them to specify
NPM
> > >
> > > > > > package name *or* plugin ID.
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > Possibly only support plugin-id for some deprecation time?  (Though
> > >
> > > > > if we publish old versions to npm, maybe we just leave it supported
> > >
> > > > > + warning
> > >
> > > > > always)
> > >
> > > > >
> > >
> > > > > - We'd use the reverse-mapping so that plugin search path will work
> > >
> > > > > if
> > >
> > > > they
> > >
> > > > > > specify package name.
> > >
> > > > > >   - E.g. "cordova plugin add cordova-plugin-file", will need
to
> > >
> > > > > > know to scan search-path directories for
> "org.apache.cordova.file".
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > Indeed!
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > > I think the different-IDs-than-package-name approach will work,
> > >
> > > > > > but I
> > >
> > > > > think
> > >
> > > > > > it's too much of a hassle to be used by third-party plugins,
> > >
> > > > > > because
> > >
> > > > it's
> > >
> > > > > > more work to have the names be different:
> > >
> > > > > >
> > >
> > > > >
> > >
> > > > > I tend to agree.  I think it *could* work, but we should think
> > >
> > > > > through if it is necessary.
> > >
> > > > >
> > >
> > > > >
> > >
> > > > > > - If their ID is the same as the package name:
> > >
> > > > > >    - They fit in more naturally with NPM
> > >
> > > > > >    - The fetching logic will be faster (since we know we don't
> > >
> > > > > > need to check CPR first)
> > >
> > > > > >    - They don't need to send a pull request and wait for a
> release
> > >
> > > > > > so
> > >
> > > > > that
> > >
> > > > > > people can install their plugin (mapper)
> > >
> > > > > >
> > >
> > > > > > If third-parties don't opt into having different package names
> > >
> > > > > > from
> > >
> > > > > plugin
> > >
> > > > > > IDs, then down the road the only plugins that will be in this
> > >
> > > > > > state are
> > >
> > > > > the
> > >
> > > > > > core plugins. Maybe that's fine?
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > > > I believe the only real question is: do we prefer a minimally
> > >
> > > > > > > easier transition by leaving all names as they are, or
do we
> > >
> > > > > > > prefer to have package names on npm that don't look out
of
> place.
> > >
> > > > > > >
> > >
> > > > > > > I think any argument that there is a technical preference
for
> > >
> > > > > > > one way
> > >
> > > > > > over
> > >
> > > > > > > the other hasn't really held up (but now would be a great
time
> > >
> > > > > > > to
> > >
> > > > > mention
> > >
> > > > > > > if that isn't true).
> > >
> > > > > > >
> > >
> > > > > > > (Note: choosing leaving names as they are still only guarantees
> > >
> > > > > > > core plugins do this, 3rd party authors may not re-publish
at
> > >
> > > > > > > all, or
> > >
> > > > rename
> > >
> > > > > > > however they want)
> > >
> > > > > > >
> > >
> > > > > > > -Michal
> > >
> > > > > > >
> > >
> > > > > > > On Wed, Feb 11, 2015 at 4:07 PM, Andrew Grieve
> > >
> > > > > > > <agrieve@chromium.org
> > >
> > > > >
> > >
> > > > > > > wrote:
> > >
> > > > > > >
> > >
> > > > > > > > Going to try and summarize my concerns with the proposal
> here:
> > >
> > > > > > > >
> > >
> > > > > > > > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill <
> > >
> > > > stevengill97@gmail.com<mailto:stevengill97@gmail.com>
> > >
> > > > > >
> > >
> > > > > > > > wrote:
> > >
> > > > > > > >
> > >
> > > > > > > > > Correct! For the first 3 months, all requests
will hit CPR
> > >
> > > > > > > > > first,
> > >
> > > > > if
> > >
> > > > > > > CPR
> > >
> > > > > > > > > fails, we will try to fetch from npm.
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > > > If users run "cordova plugin add cordova-plugin-device",
it
> > >
> > > > > > > > > would
> > >
> > > > > hit
> > >
> > > > > > > > CPR,
> > >
> > > > > > > > > fail, go to npm, succeed.
> > >
> > > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > > CPR doesn't allow non-reverse dns names. There'd be
no reason
> > >
> > > > > > > > to
> > >
> > > > > check
> > >
> > > > > > it
> > >
> > > > > > > > unless the name had at least 2 periods in it.
> > >
> > > > > > > >
> > >
> > > > > > > > If we're not using package names to detect which registry
to
> > >
> > > > > > > > use, I
> > >
> > > > > > don't
> > >
> > > > > > > > actually see any benefit in changing names.
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > > >
> > >
> > > > > > > > > If we use the mapper module, "cordova plugin
add
> > >
> > > > > > > > > org.apache.cordova.device" would be converted
to
> > >
> > > > > > cordova-plugin-device,
> > >
> > > > > > > > hit
> > >
> > > > > > > > > CPR, fail, go to npm, succeed.
> > >
> > > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > > While this works fine for our modules, I don't think
it'll
> > >
> > > > > > > > work
> > >
> > > > well
> > >
> > > > > > for
> > >
> > > > > > > > others'. Three use-cases for them:
> > >
> > > > > > > > 1. <dependency> within plugin.xml.
> > >
> > > > > > > > 2. <plugin> within config.xml (for cordova plugin
restore).
> > >
> > > > > > > > 3. cordova plugin add FOO
> > >
> > > > > > > >
> > >
> > > > > > > > All three would be solved if we enforce that packageName
==
> > >
> > > > pluginId.
> > >
> > > > > > > >
> > >
> > > > > > > > I think we should either:
> > >
> > > > > > > > - publish under npm under our existing IDs
> > >
> > > > > > > > or:
> > >
> > > > > > > > - publish under npm under cordova-plugin-FOO, and
change
> > >
> > > > > > > > plugin IDs
> > >
> > > > > to
> > >
> > > > > > be
> > >
> > > > > > > > cordova-plugin-FOO
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > > > >
> > >
> > > > > > > > > After 3 months, "cordova plugin add cordova-plugin-device"
> > >
> > > > > > > > > would
> > >
> > > > > hit
> > >
> > > > > > > npm
> > >
> > > > > > > > > first and succeed.
> > >
> > > > > > > > >
> > >
> > > > > > > > > We want to use these 3 months to get our developers
to
> > >
> > > > > > > > > update
> > >
> > > > their
> > >
> > > > > > > tools
> > >
> > > > > > > > > and use the new names for plugins to install.
> > >
> > > > > > > > >
> > >
> > > > > > > > > On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny
<
> > >
> > > > > mmocny@chromium.org<mailto:mmocny@chromium.org>>
> > >
> > > > > > > > > wrote:
> > >
> > > > > > > > >
> > >
> > > > > > > > > > Steve, npm fetch default only affects plugins
that use
> > >
> > > > > > > > > > same
> > >
> > > > name
> > >
> > > > > in
> > >
> > > > > > > > both
> > >
> > > > > > > > > > places, right?
> > >
> > > > > > > > > >
> > >
> > > > > > > > > > If we create cordova-plugin-device today,
and tell users
> > >
> > > > > > > > > > to
> > >
> > > > start
> > >
> > > > > > > using
> > >
> > > > > > > > > > cordova plugin add cordova-plugin-device,
then we will
> get
> > >
> > > > > > > > > > much
> > >
> > > > > > user
> > >
> > > > > > > > > > feedback on npm fetching far before May
18th, right?
> > >
> > > > > > > > > >
> > >
> > > > > > > > > > On Wed, Feb 11, 2015 at 1:09 PM, Steven
Gill <
> > >
> > > > > > stevengill97@gmail.com<mailto:stevengill97@gmail.com>
> > >
> > > > > > > >
> > >
> > > > > > > > > > wrote:
> > >
> > > > > > > > > >
> > >
> > > > > > > > > > > We don't have one yet but we should
pick dates soon.
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > > How about:
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > > CPR Switch to read only: Monday, May
18th NPM fetch
> > >
> > > > > > > > > > > becomes default: Monday, May 18th CPR
offline: Monday,
> > >
> > > > > > > > > > > August 17th
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > > Based on the following proposal:
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > >
> > >
> > > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > >
> > >
> > > > > >
> > >
> > > > >
> > >
> > > >
> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-
> > >
> > > > 9DpYkcmfs/edit?usp=sharing
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > >  - Need to start educating plugin developers
to publish
> > >
> > > > > > > > > > > to
> > >
> > > > npm
> > >
> > > > > as
> > >
> > > > > > > > well
> > >
> > > > > > > > > as
> > >
> > > > > > > > > > > CPR for next three months. (blog post)
> > >
> > > > > > > > > > >  - Need to educate users to install
plugins via new
> > >
> > > > > > > > > > > names (if
> > >
> > > > > > > > > > package-name
> > >
> > > > > > > > > > > is different than id). Our core plugins
are being
> > >
> > > > > > > > > > > renamed
> > >
> > > > from
> > >
> > > > > > > > > > > org.apache.cordova.device to cordova-plugin-device
> > >
> > > > > > > > > > > - Inform devs who are working with
registry directly to
> > >
> > > > > > > > > > > pull
> > >
> > > > > > > plugins
> > >
> > > > > > > > > from
> > >
> > > > > > > > > > > npm instead of CPR. After 3 months,
CPR plugins will
> > >
> > > > > > > > > > > start to
> > >
> > > > > > > become
> > >
> > > > > > > > > out
> > >
> > > > > > > > > > of
> > >
> > > > > > > > > > > date compared to npm versions.
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > > Our next plugins release (after the
one currently
> > >
> > > > > > > > > > > ongoing)
> > >
> > > > will
> > >
> > > > > > be
> > >
> > > > > > > > > > > published to npm as well as cpr.
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > > On Wed, Feb 11, 2015 at 9:10 AM, Gorkem
Ercan <
> > >
> > > > > > > > gorkem.ercan@gmail.com<mailto:gorkem.ercan@gmail.com>>
> > >
> > > > > > > > > > > wrote:
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > > > >
> > >
> > > > > > > > > > > > Is there a determined calendar
for the npm move of
> the
> > >
> > > > > plugins?
> > >
> > > > > > > > > > > > I think the scheduling of the
transition is crucial
> > >
> > > > > > > > > > > > for
> > >
> > > > those
> > >
> > > > > > who
> > >
> > > > > > > > are
> > >
> > > > > > > > > > > > using the plugin registry directly.
> > >
> > > > > > > > > > > > --
> > >
> > > > > > > > > > > > Gorkem
> > >
> > > > > > > > > > > >
> > >
> > > > > > > > > > > >
> > >
> > > > > > > >
> > >
> > > > ---------------------------------------------------------------------
> > >
> > > > > > > > > > > > To unsubscribe, e-mail:
> > >
> > > > > > > > > > > > dev-unsubscribe@cordova.apache.org<mailto:
> > > dev-unsubscribe@cordova.apache.org>
> > >
> > > > > > > > > > > > For additional commands, e-mail:
> > >
> > > > dev-help@cordova.apache.org<mailto:dev-help@cordova.apache.org>
> > >
> > > > > > > > > > > >
> > >
> > > > > > > > > > > >
> > >
> > > > > > > > > > >
> > >
> > > > > > > > > >
> > >
> > > > > > > > >
> > >
> > > > > > > >
> > >
> > > > > > >
> > >
> > > > > >
> > >
> > > > >
> > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <csantana23@gmail.com>
> >
>

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