There's a bit of a BC issue here because cordova.js needs to know what file to inject a <script> tag for, so it can load the file and then load its module. That's why I hesitated to modify the format of that file, originally. (It currently sets module.exports to an array of <js-module> info.) Like Andrew says, entirely possible to make the change, just that some care is required.
Braden On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron < jbo...@gdesolutions.com> wrote: > On Thu Nov 14 01:44 PM, Andrew Grieve wrote: > > I'm going to attempt to summarize in point form: > > > > Goal: > > - Make available the list of installed plugins and their versions to > native side & JS > > side. > > - Needed by App Harness to know whether an app is compatible with its > > bundled set of plugins. > > > > Using cordova_plugins.js: > > - It doesn't have the information that we need > > - We could add the extra information, but not easily since the file > exports an > > array instead of an object. > > - This file is not currently parsed by the native layer, so having the > info here > > would be an extra IO on start-up. > > > > Great summary :) > > Is it difficult to rename ' cordova_plugins.js' to something more broad > 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an > object? > Since it's generated code, first impression is there's no BC issue other > than doing another prepare. > > Doesn't seem like there's a way to avoid the extra IO on the native side > (e.g. cordova_meta.js). If the detailed list of installed plugins is in > xml, how will the JS side access it? > > Broader problem is there's no single cordova meta file that's shared > between native & js. Considering that on some platforms, there's only > JavaScript, putting the information in JSON seems like a good move. > >
