cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Food for thought over the holidays
Date Wed, 19 Dec 2012 19:39:03 GMT
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
  -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

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
        -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
         -E.g. enforce that all JS files have a top-level directory called
       -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

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