The idea for plugin dev outside of plugins/ folder was to use "plugin add --link". Matter of fact, braden suggested that "plugin create" should default to --link-ing to some external location so that you don't risk deleting your only copy inside plugins/. (I personally don't think thats a necessary concern, but I think its a conversation for later).
I'm not even sure what a 'watch' would do, just uninstall & install each time the plugin changes? I think that ends up being just slightly worse than the current proposal if you factor in that we already do support --link (except without the above change its been useless). However, we may still want some form of 'watch' command for devs using plugman directly. I had assumed that those devs just edit in place, since they don't use a prepare step anyway. -Michal On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI <anis.ka...@gmail.com> wrote: > If we're talking about developing plugins inside the > plugins/org.myplugin.id folder than I think it's a great workflow and > I would just hide the cached version of plugin.xml inside that > plugins/org.myplugin.id folder. > > However, if you're developing a plugin outside of a cordova CLI > project, I think a `watch` (and add --watch) command is more > appropriate. One of the reasons you would develop a plugin outside of > a cordova CLI project is for easier version control (each plugin would > have its own repository). The other cool thing about `watch` is that > it would copy the files that have actually changed and not everything > (some plugins have a LOT of files [1]). > > [1] https://github.com/phonegap/phonegap-facebook-plugin > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <wjamesj...@gmail.com> wrote: > > +1 This is a cleaner workflow and should reduce some confusion. > > > > -James Jong > > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > >> Just to add, the reason for the "if" statement in step (2) is that > >> uninstall & reinstall take a lot longer than just moving a few files, > which > >> is the 99.9% case for most end users who aren't making modifications to > >> plugins. > >> > >> This way, we only do the heavy lifting if your plugin structure actually > >> changed. Doing it automatically means we no longer have to advise users > >> that making edits inside plugin/ folder is useless. Now we just advise > >> them to run "prepare" after making changes to either www/ or plugins/. > >> > >> This key insight was Braden's idea and I think its just an awesome > change > >> for workflow. > >> > >> -Michal > >> > >> > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson < > bra...@chromium.org>wrote: > >> > >>> Michal and I were discussing how to make the plugin developer > experience > >>> better, by having `cordova prepare` update the platform projects > properly > >>> when you change a plugin in place. > >>> > >>> I propose the following changes: > >>> > >>> 1. On plugin install, we cache the plugin.xml in $PROJECT/.cordova > >>> somewhere. > >>> 2. On 'cordova prepare', compare each plugin's plugin.xml against the > >>> cached one. > >>> a. If they have changed, uninstall the plugin using the old > plugin.xml, > >>> then reinstall using the new one (and update the cached plugin.xml). > >>> b. If they are identical, copy all the native code files from the > >>> plugin into the project again. > >>> > >>> The idea is that you can change your plugin's native code, JS modules, > or > >>> assets, and after a prepare you'll be running the latest. We already > have > >>> cordova plugin add foo --link, but it wasn't very useful. This will > make > >>> plugin development a much smoother flow, without too much > implementation > >>> effort. > >>> > >>> Checking for changes to plugin.xml lets us know that no files have been > >>> added or removed, that <config-file> edits haven't changed, and so on, > >>> meaning that simply copying the native code again will be sufficient. > >>> > >>> What do people think? Any gotchas that I overlooked? > >>> > >>> Braden > >>> > > >
