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 Tue, 17 Feb 2015 16:28:39 GMT
On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve <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> 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.

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.


> - 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>
> > > 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>
> > > > 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
> > >
> > > > > 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>
> > > > > > 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
> > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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