cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <>
Subject Re: What's your daily workflow for cordova development?
Date Tue, 03 Sep 2013 15:50:50 GMT
Responses inline.

On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron <> wrote:

> On Mon Sep 2 07:34 PM, Brian LeRoux wrote:
> > Here's a shot. Ideal flow tomorrow might be to generate a plugin called,
> lets say,
> > "Echo" that matches something we'd find in our docs, automate add/remove
> > with some sort of watch command. That way ppl are writing to the plugin
> spec
> > from the beginning instead of refactoring a plugin out of a native
> project.
> >
> > Thoughts?
> >
> Two new features could be useful from cli:
> a) Create an initial plugin from a template
> cordova plugin create [path] [name]
> e.g.
> > cordova plugin create F:/GitHub/MyPlugin MyPlugin
I agree, this would be useful. It's pretty easy to implement, just not a
high priority. Do you want to file a JIRA ticket for it?

> b)  Update all plugins from a cordova application
> cordova plugins update
> e.g.
> > cordova create F:/CordovaApp
> > cd F:/CordovaApp
> > cordova plugin add F:/GitHub/MyPlugin
> > cordova plugins update
> The implementation is likely tricky, how to detect plugin modification?
> Version check?
> I image it would remove & install the new plugin.
> > cordova plugins update -local
> Could  be useful to force the removal and reinstall of only local plugins
> (from a filesystem path) / under development...
There are plans for an cordova plugin upgrade [foo] command, but you're
correct that it's tricky, how we handle dependencies and so on. I've got a
draft of a plan for it, but I haven't finished it and sent it around.

I think the ideal solution to the larger problem of in-place-updating
plugins would be to have the plugin installation logic running on every
prepare (and then a cordova watch command that re-runs prepare when the
plugins change). My ideal flow is:
- I add the plugin via symlink, so that it's pointing to the same place on
- I change some file, native or JS or even plugin.xml
- cordova watch notices that and re-runs prepare, which updates everything

But that takes some doing: what if I removed or renamed a native file? It
needs to know which one so that it can be removed, but for that it needs to
cache the old plugin.xml, etc. etc. All of these are solvable problems, but
it will be some time before all the pieces are in place for this flow.

Ultimately, we need to optimize first for app developers, and then for
plugin developers. On the other hand, the fact that we're now concerned
with the latter suggests that the main app developer flow is pretty solid,
which I think it is. With the exception of how painful it currently is to
update a platform (rather than a plugin), but we've got plans under
discussion for that problem too.

> I haven't gotten around to running .spec tests but something simple as:
> c) Running tests within plugin directory
> cd F:/GitHub/MyPlugin
> cordova plugin test
> [Test #1] Passed
> [Test #2] Failed: Reference error foo doesn't not exist
> Would be very useful.
We want some kind of per-plugin testing story, rather than our big
mobile-spec test suite. There are enough problems and questions here,
though, that we've just left things as they are for now. That is, one
monolithic mobile-spec for all of Cordova's core plugins, and plugin
authors are on their own - which generally means that third-party plugins
have no tests :(


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