cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Wed, 27 Feb 2013 21:24:44 GMT
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).


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
>* 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)
>On Mon, Feb 25, 2013 at 10:32 AM, Braden Shepherdson
>> 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
>> 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
>> 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
>> of truth for what is or isn't installed.
>> Under this model, plugin add/rm become fancy aliases for cp -R and rm
>> 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
>> 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
>> idea past people before I start fundamentally changing how the tool
>> I think this will make many parts of the code simpler to read and
>> and make the behavior of the tool much clearer and less magical to
>> Braden

View raw message