cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Updating plugin code on prepare
Date Thu, 26 Sep 2013 17:09:32 GMT
I love the idea of a watch command.


On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> Forgot about the existence of --link for a second. I think this is a
> good solution (not temporary). watch can be an enhancement to this
> solution. This might get people like Joe Bowser and other people who
> do native dev to give cordova-cli a try (only maybe though).
>
> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <braden@chromium.org>
> wrote:
> > If the proposal above is temporary, what's permanent? cordova watch? I
> want
> > to make sure we're on the same page.
> >
> > Braden
> >
> >
> > On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI <anis.kadri@gmail.com>
> wrote:
> >
> >> No I didn't mean implement `plugman --watch`. I don't think plugman
> >> needs a `watch` command.
> >>
> >> I was indeed talking about `cordova watch` which should watch for
> >> changes in plugins/ (and maybe in merges/ and www/ as well) and update
> >> the platform projects (prepare?) on every change.  I am happy to know
> >> that it's on the wish list.
> >>
> >> As far as the original proposal, I believe it is a descent temporary
> >> solution for plugin developers who want to use cordova-cli.
> >>
> >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny <mmocny@chromium.org>
> wrote:
> >> > Braden, thats has been on the wish list (cordova watch), but I suspect
> >> Anis
> >> > was suggesting something different with plugman --watch, to do
> >> specifically
> >> > with plugin development.  Am I right, Anis?  How does your idea
> compare
> >> > with using --link with cordova watch?  Would plugman --watch be useful
> >> for
> >> > non cli projects?
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >> braden@chromium.org>wrote:
> >> >
> >> >> 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 <mmocny@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.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