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 <agri...@chromium.org>
wrote:
> On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmo...@chromium.org>
> wrote:
>
> > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve <agri...@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 <mmo...@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 <agri...@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 <
> stevengil...@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 <
> > mmo...@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 <
> > > stevengil...@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.er...@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-unsubscr...@cordova.apache.org
> > > > > > > > > For additional commands, e-mail:
> dev-h...@cordova.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
