cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Moving plugin JS files around
Date Tue, 15 Jan 2013 21:35:35 GMT
Okay, I'm feeling the need to reboot a bit on this. I'd like to think this
through in terms of cordova-cli commands.

First thing I'd like to clarify is where things go when we run "cordova
platform add" vs "cordova plugin add"?
I *think* currently how it works is that "cordova platform add ios":
- Downloads cordova-ios (either from git or from a tar) into a cached
location: "cordova-cli/lib"
- Runs cordova-cli/lib/cordova-ios/bin/create project-path/platforms/ios
com.company.app AppName

Is this correct?


Now, what are the plans for "cordova plugin add"? Will it:
- Download the plugin source to "cordova-cli/lib" as well? Or does it put
it in project/plugins?

Once it's downloaded the source, it uses plugman to copy source files into
project/platforms/ios. How does "cordova plugin remove" work? Does it rely
on the original plugin.xml file to tell it which files to delete? or does
it write a manifest when it installs the plugin?

I remember hearing that there were plans to use npm to install plugins, but
looking at the docs, npm doesn't support installing to directories other
than node_modules. Do we still plan to use this? Maybe just let it install
into node_modules and then move them out of there? Maybe we have a
project/plugins/node_modules directory?




Here's the cordova-packager workflow. The lines suffixed with *** are the
ones that are different from existing cordova-cli behaviour:

"cordova project create":
- Creates project template

"cordova platform add ios"
- Downloads cordova-ios (either from git or from a tar) into cordova-cli/lib
- Since this is the first platform being added, this will trigger a similar
download of cordova-js into cordova-cli/lib
- Runs cordova-ios/bin/create platforms/ios com.company.app AppName
- Copy cordova-cli/lib/cordova-js --> project/platforms/cordova-js   ***
- Removes platforms/ios/www

"cordova plugin add file"
- Download plugin files
- copy scripts listed in plugin.xml into
platforms/cordova-js/lib/$COMMON_OR_PLATFORM/plugin/$PLUGIN_NAME/...  ***

"cordova build":
- run cordova packager for the added platforms.   ***
- copy resulting JS into platform/www directories.


Notes about this workflow:
-The only change to the require paths (and cordova-js directory structure)
in the workflow is the addition of the plugin-name directory under
lib/common/plugin.
-This should be pretty easy to debug since it's just automating the dev.
workflow
-This will eliminate the need to commit pre-built .js files into platform
repos.
-This will make it easier to have projects that build against
cordova-js/master since it doesn't require pre-built .js files.



Here's the "prebuild things" workflow. The lines suffixed with *** are the
ones that are different from existing cordova-cli behaviour:

"cordova project create":
- Creates project template

"cordova platform add ios"
- Downloads cordova-ios (either from git or from a tar) into cordova-cli/lib
- Runs cordova-ios/bin/create platforms/ios com.company.app AppName
- Removes platforms/ios/www

"cordova plugin add file"
- Download plugin files
- copy script listed in plugin.xml into platforms/ios/plugin-js/file-ios.js

"cordova build":
- copy prebuilt cordova.ios.js from platforms/ios/CordovaLib ->
platforms/ios/www/cordova.js
- concat platforms/ios/plugin-js/* into platforms/ios/www/cordova-plugins.js


Notes about this workflow:
-Then change to the require path will be more significant. Maybe
"cordovaplugin/file/Entry"
-We would need to build and commit each plugin's .js file
-Packaging within the plugin when developing may have to be done either way
in order to run its unit tests.
-This eliminates the need to download the cordova-js repo, but does require
that each platform have a pre-built version of cordova.js in them.
-In order to run against cordova-js/master, you'll have to manually build
the .js file and clobber platform/ios/CordovaLib/cordova.ios.js.
-Changes to the packager will mean having to re-build all plugins, or
remaining backwards-compatible with plugins built with old packager versions




How we deal with mapping module -> symbol is tangental (I think) to which
approach we take. My guess to this is to have cordova-cli record a list of
all plugins that it has installed, and for each plugin to have a symbols.js
file that will provide this info. If there is a dependency from one plugin
on another, then it can require() the other plugin's symbols file to ensure
that it gets loaded first.



Phew! so, lots of questions & suggestions in there. I'm less sure than ever
as to which approach is better, although I think I'm somewhat leaning
towards the second one now instead of the first one.


I'm going to hold off on moving any files around until we get a better
grasp on this. Instead, I think I'll first work on creating a symbols.js
file for each plugin.


















On Mon, Jan 14, 2013 at 8:40 PM, Jesse <purplecabbage@gmail.com> wrote:
>
> >> Where do you see it overwriting things? I see a few clobbers / merges
>>
> ...
> Sorry, off topic ...
>
> >> Are you sure? I just tested this ...
> Yeah, I was wrong about cordova.plugin, I thought I saw it somewhere, but
> indeed, they are destroyed when bootstrapped.
> One thing I did notice is that our API does not have a method to state
that
> for example,
> "cordova/plugin/accelerometer" needs to be mapped to
> navigator.accelerometer, although I am not sure this should be the job of
> the 'define' function.  Still chewing on this ...
>
>
> On Mon, Jan 14, 2013 at 1:42 PM, Andrew Grieve <agrieve@chromium.org>
wrote:
>
> > Are you sure?
>
>
>
>
>
> --
> @purplecabbage
> risingj.com

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