Food for thought over the holidays

[Andrew Grieve <ag...@google.com>]

Here's a proposal (with some unknowns) on how improve the state of JS
within plugins (following on from the earlier thread on the subject).

What cordova-client currently does (using iOS as the example):
  -Copies www -> platform/ios/www
  -Copies platform/ios/cordova.ios.js -> platform/ios/www/cordova.js
  -Copies config.xml -> platform/ios/www/config.xml, and customizes
per-platform
  -Install plugin native code / assets via plugman

What cordova-client should do to better support plugins:
  -Instead of considering JS the same as other assets, treat it as a
first-class thing.
  -Build cordova.js from source (check it out as a sibling to
cordova-ios.git)

How we can enhance plugins:
  -Change from listing module->symbol mapping within common.js &
platform.js, to listing this within the plugins themselves.
     -Maybe it could go in the plugin.xml? (clobbers / defaults / merges)
     -Another option is to dedicate a single .js file for exporting this
info.
        -The plugin.xml would define which .js file is the symbols.js file
        -Or just hard-code it to symbols.js
        -This would be a normal module that would export the clobbers /
defaults / merges JSON.
  -As a part of the cordova-client build step, collect all of the
module->symbol mapping info from plugins and put it into a single
symbols.js file.
    -Problem! Sometimes order matters!
       -The ordering is generally the same as inter-plugin dependencies
       -We should use the notion of dependency info in the package.json
file when determining symbol export order.
         -E.g.: FileTransfer & LocalFileSystem depend on File
         -Or, is there dependency info in the plugin.xml?
       -Have the symbols.js file export an array of the DAG of the
{clobbers / defaults / merges}.
         -We could probably do some optimizations around collapsing
multiple non-dependent entries together.
    -Problem! What if plugin wants different JS on iOS vs Android (we
really want to encourage x-platform plugins)
       -We should allow plugins to use the same directory structure as
cordova-js
         -E.g. enforce that all JS files have a top-level directory called
"common|android|ios|etc"
       -We can then merge all of the files together and run jake on the
whole thing
       -We can have an opt-in toggle in the plugin.xml to maintain
compatibility with old plugins
         -Or maybe just use the presence of a symbols.js file?
         -Old plugins will continue to treat their JS as assets

Re: Food for thought over the holidays

[Andrew Grieve <ag...@chromium.org>]

Moving JS into their own repositories is the motivation.

My thinking was that cordova-cli would use tags when checking out
cordova-ios, cordova-js, etc, instead of checking them out at master. When
the user wants to update to a new version, they could do "cordova update
[version]" or something like that.


On Thu, Jan 3, 2013 at 3:13 PM, Brian LeRoux <b...@brian.io> wrote:

> I thought this meant we move the JS out of CordovaJS and start moving
> it into plugin packages.
>
> On Thu, Jan 3, 2013 at 12:02 PM, Filip Maj <fi...@adobe.com> wrote:
> > time? If so, I disagree. The reason we tag the JS and need consensus on
> it
>

Re: Food for thought over the holidays

[Brian LeRoux <b...@brian.io>]

I thought this meant we move the JS out of CordovaJS and start moving
it into plugin packages.

On Thu, Jan 3, 2013 at 12:02 PM, Filip Maj <fi...@adobe.com> wrote:
> time? If so, I disagree. The reason we tag the JS and need consensus on it

Re: Food for thought over the holidays

[Filip Maj <fi...@adobe.com>]

>> What cordova-client should do to better support plugins:
>>   -Instead of considering JS the same as other assets, treat it as a
>> first-class thing.
>>   -Build cordova.js from source (check it out as a sibling to
>> cordova-ios.git)
>
>Yes.

Are you suggesting checking out cordova-js' master and building it each
time? If so, I disagree. The reason we tag the JS and need consensus on it
to go through the release ceremony is to make sure that the shared code
that is the JS works for all platforms. If we start building js from
source+master every time I think we will be introducing instability.

Re: Food for thought over the holidays

[Brian LeRoux <b...@brian.io>]

(Happy holidays everyone!)


> What cordova-client should do to better support plugins:
>   -Instead of considering JS the same as other assets, treat it as a
> first-class thing.
>   -Build cordova.js from source (check it out as a sibling to
> cordova-ios.git)

Yes.


> -Change from listing module->symbol mapping within common.js &
> platform.js, to listing this within the plugins themselves.
> -Maybe it could go in the plugin.xml? (clobbers / defaults / merges)

This would be good as a transition step.


> Or, is there dependency info in the plugin.xml?

I *think* this would be the right thing to do.


> -Problem! What if plugin wants different JS on iOS vs Android (we
> really want to encourage x-platform plugins)
> -We should allow plugins to use the same directory structure as cordova-js
> -E.g. enforce that all JS files have a top-level directory called "common|android|ios|etc"

ya this would be great too


> -Old plugins will continue to treat their JS as assets

yes, totally