What does a watch mean? - if I reboot, is it still watched? I think it would be best to consider separating development from packaging in your use-case for workflow. If I am going to develop featureX as a plugin I would :
1. create a project for a single cordova platform, and develop the feature as a native piece, and a js piece. 2. test thoroughly 3. create a project for a second cordova platform, and develop the native bit, preserving the js from 1 4. test thoroughly 5. repeat steps 3+4 for any remaining platforms 6. package featureX as a plugin by organizing relevant bits in the correct folder structure, and adding a plugin.xml 7. test each platform by installing with plugman 8. publish We seem to have this notion come up repeatedly that our users + plugin developers are working on multiple platforms at the same time, which I think is entirely false. I also think we're trying to help the wrong people; If I am a developer who is working on multiple platforms at once, and I have a bunch of devices attached, I probably also have the skills to set up my own grunt continuous integration system. Setting up tooling for potential plugin developers is the wrong approach, imho. We should actually just go and implement some new plugin and evaluate the process instead of creating and imposing a specific workflow. @purplecabbage risingj.com On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux <b...@brian.io> wrote: > I love the idea of a watch command. > > > On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI <anis.ka...@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 <bra...@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.ka...@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 <mmo...@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 < > > >> bra...@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 <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 > > >> >> > > >>> > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> > > >
