cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Moving plugin JS files around
Date Tue, 15 Jan 2013 21:59:34 GMT
Responses in-line below.

On 1/15/13 1:35 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:

>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?

Yes.


>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?

Puts the plugin source under the ./plugins directory of your project dir.

>Once it's downloaded the source,

FYI it may download but it doesn't have to if you point it to a local path.

> 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?

It also uses plugman to do removal (plugman does both). I'm not sure how
plug man does it, but I think yes, it uses plugin.xml to reverse the
operations that an install would do.

>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?

I'm not sure. Max Ogden wrote one that uses npm. We are going with a
manifest + tool route separate from npm. The discovery of plugins may use
NPM, though.

>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.

Sounds good.

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>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
View raw message