Summarizing conclusions so far (not 100% we all agree on this, please do speak up):
- PluginId and Npm Package Name should be the same. We cannot force this for all plugins, but we can set the tone with core plugins. - We will change all plugins to use the cordova-plugin-* name/id. - We will bump MAJOR version to signal this change, and so plugins that depend on core plugins know to update to reflect the id change. - Publish old versions of plugins with the new package name but old plugin ids to npm. - CPR will be hit first, then fallback to npm, for the first N months. - We could go directly to npm first if the name is known to not match CPR requirements (i.e. cordova-plugin-* is known to not be in CPR by existing plugin id requirements) - Mapper module can help transition users of old ids to new package names, by warning that plugins have moved, and (perhaps?) automatically redirecting. - If we drop the automatic redirection requirement, we could just update CPR plugins with <info> inform users of the change. I think thats it.. Steve, mind updating us on how far along you are, and with what you would like help? -Michal On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny <mmo...@chromium.org> wrote: > 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 <agri...@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 <mmo...@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 <mmo...@chromium.org> >>> wrote: >>> >>> > >>> > >>> > On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve <agri...@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 <mmo...@chromium.org> >>> >> wrote: >>> >> >>> >> > On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill < >>> stevengil...@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 < >>> csantan...@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 < >>> cla...@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: mmo...@google.com [mailto:mmo...@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 < >>> >> > agri...@chromium.org >>> >> > > > > <mailto:agri...@chromium.org>> >>> >> > > > > >>> >> > > > > wrote: >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny < >>> >> > mmo...@chromium.org >>> >> > > > > <mailto:mmo...@chromium.org>> >>> >> > > > > >>> >> > > > > > wrote: >>> >> > > > > >>> >> > > > > > >>> >> > > > > >>> >> > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve >>> >> > > > > >>> >> > > > > > > <agri...@chromium.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: >>> 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<mailto: >>> >> > > > > dev-unsubscr...@cordova.apache.org> >>> >> > > > > >>> >> > > > > > > > > > > > > > For additional commands, e-mail: >>> >> > > > > >>> >> > > > > > dev-h...@cordova.apache.org<mailto: >>> dev-h...@cordova.apache.org> >>> >> > > > > >>> >> > > > > > > > > > > > > > >>> >> > > > > >>> >> > > > > > > > > > > > > > >>> >> > > > > >>> >> > > > > > > > > > > > > >>> >> > > > > >>> >> > > > > > > > > > > > >>> >> > > > > >>> >> > > > > > > > > > > >>> >> > > > > >>> >> > > > > > > > > > >>> >> > > > > >>> >> > > > > > > > > >>> >> > > > > >>> >> > > > > > > > >>> >> > > > > >>> >> > > > > > > >>> >> > > > > >>> >> > > > > > >>> >> > > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > -- >>> >> > > > Carlos Santana >>> >> > > > <csantan...@gmail.com> >>> >> > > > >>> >> > > >>> >> > >>> >> >>> > >>> > >>> >> >> >
