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 <purplecabb...@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 <agri...@chromium.org> wrote: > > > Are you sure? > > > > > > -- > @purplecabbage > risingj.com
