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, 24 Feb 2015 03:44:46 GMT
Just thinking out loud..

I guess it wouldn't actually do that unless you are using actual npm cli to
install plugins.  With the current plan we are still just using
cordova/plugman to fetch using the npm lib, and so can probably resolve
peerDependencies whenever/however we want (like auto-fetching only once the
platform is added).

If we did move to top-level package.json and installing dependencies via
npm, it may be a little annoying to have that message.

I guess the reason we are discussing dropping <dependency> anyway was for
the move to using npm cli directly, and since we are still a ways away from
that, I guess we can punt this change for now and keep using a tag?

-Michal

On Mon, Feb 23, 2015 at 9:52 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> I suppose it's workable, but it seems worse than what we currently have.
> E.g. I don't care about Android, but npm peerDependencies will complain
> until I've installed the android.support.v4 plugin into my node_modules.
>
> On Mon, Feb 23, 2015 at 4:26 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> I scanned the core plugins, and only contacts uses platform specific deps,
>> and only for 2 BB plugins.
>>
>> Also scanned the top 20 non-core plugins from CPR, and:
>>
>> - com.cranberrygame.phonegap.plugin.ad.admob
>>   - depends on google-play-services only on android, but that plugin only
>> supports android.
>> - com.google.cordova.admob   (Note: not published by com.google..)
>>   - Same as above
>> - plugin.google.maps
>>   - Same as above
>>   - also depends on android.support.v4 for android only (but its also an
>> android only plugin)
>>   - also depends on com.googlemaps.ios for ios only (but its an ios only
>> plugin)
>> - net.yoik.cordova.plugins.screenorientation
>>   - Depends on com.blackberry.app only for BB (but its BB only plugin)
>>
>>
>> So.. this is not an uncommon use, but it seems unnecessary in all cases
>> I've found so far.
>>
>> -Michal
>>
>> On Mon, Feb 23, 2015 at 4:10 PM, Michal Mocny <mmocny@chromium.org>
>> wrote:
>>
>> >
>> >
>> > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <agrieve@chromium.org>
>> > wrote:
>> >
>> >> You can use plugin.xml <info> to print a message upon installation.
>> >>
>> >> Plugins can specify dependencies on a per-platform basis. Don't think
>> we
>> >> can capture this with package.json without using custom keys.
>> >>
>> >
>> > Do we need to?  I mean, this is a breaking change, but perhaps once that
>> > is acceptable in practice.  I.e. Contacts depends on
>> com.blackberry.utils,
>> > but that plugin only supports the BB <platform> and so shouldn't be
>> > installed on others.
>> >
>> > In theory there exists a plugin which supports all platforms but is only
>> > explicitly needed for one platform as a dependency..  But I don't know.
>> > Does the issue come up in practice?
>> >
>> >
>> >>
>> >>
>> >>
>> >> On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny <mmocny@chromium.org>
>> >> wrote:
>> >>
>> >> > 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