cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Updating plugin code on prepare
Date Wed, 25 Sep 2013 13:44:11 GMT
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.kadri@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 <wjamesjong@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 <mmocny@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 <
> braden@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
> >>>
> >
>

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