We've had a vague feature planned for a while now to do a cordova watch. It would watch your plugins/, www/, and merges/* for any changes. If any changes are detected, it would re-run cordova prepare, so that your native projects are always up-to-date.
I'm open to checking (hashes?) which files have changed and which have not, but hashing them all is touching them all anyway, and it might be faster for small files to just copy them instead of checking first. We'll have to try it and see; for v1 I'm going with the simple option of copying everything. Braden On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny <mmo...@chromium.org> wrote: > 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 > > >>> > > > > > >
