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