This would be my ideal workflow $ cordova plugin add /path/to/plugin $ cordova plugin watch /path/to/plugin # detects if plugin is installed (otherwise fails), watches for changes and automatically updates CLIPROJECT/plugins and re-runs prepare.
maybe even `add --watch` (CTRL+C to cancel). We don't have to worry about version numbers. We can just watch the filesystem for changes (and there are node packages that do that such as chokidar [1]) I think update/upgrade for plugins and cordova are more for app developers than plugin developers. As far as testing, I think it should be part of the plugin itself and not part of giant test suite (like mobile-spec). Also I remember us talking about giving the freedom to use whatever testing framework they want as long as it spits out a proper test result format. Was it TAP [2]? [1] https://github.com/paulmillr/chokidar [2] http://en.wikipedia.org/wiki/Test_Anything_Protocol On Tue, Sep 3, 2013 at 8:50 AM, Braden Shepherdson <bra...@chromium.org> wrote: > Responses inline. > > > On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < > jbo...@gdesolutions.com> 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 > disk. > - I change some file, native or JS or even plugin.xml > - cordova watch notices that and re-runs prepare, which updates everything > properly. > > 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 :( > > Braden
