cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Wed, 27 Feb 2013 23:44:02 GMT
Poking my nose in…

Aside from 100% agreeing that the user's www should no be polluted, I would also like to flag
that perhaps being able to re-add a plugin to a platform would be useful.

If you are not pushing your platforms dirs to your repo, for instance… you will need some
way to get your plugins back into your platforms on a fresh pull… currently, you would have
to completely remove and re-add the plugins or they would complain about already having been
added (due to their existence in the ./plugins dir).

In my dream world, something like npm's or bower's "install" would be really nice… being
able to specify plugins in a config file (or even just have them in the plugins dir from a
previous "add") and being able to then add them to a fresh platform after a "cordova platform
add …" using some cordova command…

Also, IIRC this thread also involves being able to have JS only plugins… this would be fantastic
as well.

- Tommy

On 28/02/2013, at 8:32 AM, Braden Shepherdson <> wrote:

> I'm on the fence about native plugin code. I think iOS has some
> complications there.
> Over the course of my work on the installation prototype, I've actually
> moved to copying plugin www files on every prepare, that works great.
> For native code, I wonder if that's best done on add/remove. I was mostly
> thinking about www files for the original proposal.
> Braden
> On Wed, Feb 27, 2013 at 4:24 PM, Filip Maj <> wrote:
>> Couple notes before I add some comments:
>> - in general plugin add and rm is COMPLETELY delegated to the plugman
>> tool. See [1]. Most of the code linked is error checking, otherwise it
>> shells out to plugman.. With one exception..
>> - what happens in [2]. Which is the point Braden brought up about
>> polluting the user's www. Totally agree this should change. At the time of
>> writing that I dropped a TODO [3] that this was a likely bad assumption.
>> - the "what plugins are installed" code is already a `ls plugins/` run [4].
>> Now going back to your proposal:
>> 1. Never pollute user's www. I completely agree with this. Time to
>> refactor that out.
>> 2. Use existence of directories under the ./plugins dir to identify which
>> plugins are installed. Yep. Already does that as shown in [4].
>> If I understand correctly, you are proposing we run a plugin installation
>> (I.e. Copy over appropriate files and edit config files) every time
>> cordova prepare is run. This would mean that every time we run prepare, we
>> have to recreate a native cordova project (otherwise we'd be installing
>> plugin files into the native project on every command). I'm not sure I
>> agree with this.. I have to think more about it..
>> I think this conversation boils down to: should we be recreating cordova
>> projects on every command, or keep the native projects "persistent" across
>> commands (which is currently how it operates).
>> [1]
>> [2]
>> [3]
>> [4]
>> On 2/25/13 8:24 AM, "Michal Mocny" <> wrote:
>>> Just to clarify this in my head:
>>> * Since we have a prepare step now, you propose moving some of the logic
>>> that used to run on plugin add out into the prepare step.  That sounds
>>> good.
>>> * You want to fix how we track which plugins are installed by going to
>>> source instead of some config file.  That sounds good.
>>> * You want to fix a bunch of stuff with the prepare step (including the
>>> current add logic).  I can't really comment on specifics here, but I guess
>>> this is not as radical of a change as I thought on first pass.
>>> I briefly asked you offline but wanted to bring it into the ML: How does
>>> this proposal affect our current plan for plugin upgrading?  (Your answer,
>>> paraphrasing, was that prepare step should ideally be stateless and start
>>> from any clean state.  Thus, upgrade is simply an rm & add & prepare)
>>> -Michal
>>> On Mon, Feb 25, 2013 at 10:32 AM, Braden Shepherdson
>>> <>wrote:
>>>> I'm running into several problems with the current implementation of
>>>> cordova-cli:
>>>> * There's no single source of truth for what plugins are installed. It
>>>> uses
>>>> the presence of a plugin's name in the www/config.xml currently. This
>>>> doesn't work for JS-only plugins, and there are some, especially on
>>>> other
>>>> platforms.
>>>> * It's polluting (maybe clobbering!) the user's www/ during plugin add.
>>>> * It expects plugins to have a www/ directory it copies whole into the
>>>> top-level www/, rather than honouring <asset> tags as per docs.
>>>> My proposal is to rewire cordova-cli according to two principles:
>>>> 1. We never pollute the user's www/ with anything. Full stop.
>>>> Everything we
>>>> do automagically goes into the platform directories at cordova prepare
>>>> time.
>>>> 2. We use the existence of absence of directories in plugins/ as the
>>>> source
>>>> of truth for what is or isn't installed.
>>>> Under this model, plugin add/rm become fancy aliases for cp -R and rm
>>>> -rf.
>>>> No magic or copying of JS or native files or config editing or anything
>>>> else happens on plugin add: We just copy the directory into plugins/.
>>>> Then on cordova prepare, we copy native files into the platforms, edit
>>>> platform-specific config files to include <plugin> tags and permissions
>>>> and
>>>> list the native files.
>>>> iOS makes this hard, since it has a project file that lists all native
>>>> files in the project. We can get around this by putting all plugin files
>>>> into a subdirectory like src/plugins. Then on cordova prepare we can get
>>>> every file in that directory, remove them from the project file, delete
>>>> them, then copy every plugin's native files and add them to the project
>>>> file. Then the project file always matches the current load of plugins.
>>>> I'm volunteering to do the work required for this. I just want to run
>>>> the
>>>> idea past people before I start fundamentally changing how the tool
>>>> works.
>>>> I think this will make many parts of the code simpler to read and
>>>> document,
>>>> and make the behavior of the tool much clearer and less magical to
>>>> users.
>>>> Braden

View raw message