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> >> >> > > > >> >> > > >> >> > >> >> >> > >> > >> > >
