cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject cordova-cli plugin add/remove/prepare proposal
Date Mon, 25 Feb 2013 15:32:15 GMT
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

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