cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Updating plugin code on prepare
Date Tue, 24 Sep 2013 19:09:16 GMT
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

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.


On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <>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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message