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