I see your point. We have chatted about moving platform specific JS into the platform repos for a while. I agree that is something we should do now.
On Sat, Jan 10, 2015 at 5:27 PM, Andrew Grieve <agri...@chromium.org> wrote: > An example is android-3.7.0 adding an extra prompt() on start-up that > retrieves a nonce from the native side. If any pre-3.7.0 were to use this > newer JS, it would likely show a prompt() on start-up. > > The app plugin is not a real plugin only because we want it installed be > default. > Is this worth revisiting? Ripping it out and having it install on platform add android or something? We handle this case with a transform in browserify for both android + fireOS > I think the right thing to do here is to move platform-specific JS into the > platform repositories. This would be really nice from a > being-able-to-commit-dependent0-changes-in-one-commit standpoint as well. > Then, browserify will need to know to take modules from cordova-js, plugin > JS, as well as platforms/android/js-modules (we create this), when creating > cordova.js. We could avoid having multiple copies of files in the interim > by telling grunt where the platform is and actually delete the platform > files from cordova-js for both paths. > > Sound right? > Does sound about right. What do you mean by "delete the platform files from cordova-js for both paths." This doesn't solve the initial problem you brought up though. That older platforms need older cordova-js files to work. Multiple ways to approach this. 1. When browserify lands, give cordova a major version jump and set a baseline of what versions of platforms it supports 2. Add checks to cordova prepare logic to use non browserify method for platform versions less than some baseline Any other options? I will whip this into a proposal soon so we can all review it and create issues once we finalize the design. > > > On Fri, Jan 9, 2015 at 5:58 PM, Steven Gill <stevengil...@gmail.com> > wrote: > > > What are some examples of older platforms that can't use the newer exec > > code? I don't think this is a usecase that is very common (using fairly > > outdated platforms with new cli). Maybe a solution would be that newer > > versions of the cli don't work with those old versions of platforms. > > > > In terms of app plugin, we have a transform for that very case part of > the > > browserify code. > > > > > https://github.com/apache/cordova-js/blob/master/tasks/lib/require-tr.js#L52-L63 > > . > > > > > > Do you know the reasoning behind keeping app plugin a part of > > cordova-android repo and not breaking it out like all of our other > plugins? > > > > > > On Fri, Jan 9, 2015 at 11:50 AM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > > > On Fri, Jan 9, 2015 at 2:26 PM, Steven Gill <stevengil...@gmail.com> > > > wrote: > > > > > > > Thanks for PRs. > > > > > > > > Andrew, the browserify method builds a cordova-js for each of the > > > installed > > > > platforms (at prepare time) and copies it over into the platforms www > > > > directory (platforms/android/assets/www, etc). We shouldn't have to > > move > > > > platform specific js into platform folders because it is still > > building a > > > > unique cordova js file for each platform. > > > > > > > > > > I wouldn't want a newer version of cordova-js's exec() bridge code > being > > > used with an older version of the platform. Likewise, Android has an > > "App" > > > / "CoreAndroid" plugin, that assumes it's lockstep with the .java files > > > within the platform. > > > > > > > > > > > > > > > > > On Fri, Jan 9, 2015 at 10:41 AM, Josh Soref <jso...@blackberry.com> > > > wrote: > > > > > > > > > Steven Gill wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/cordova/apache-blog-posts/blob/master/2015-01-08-tools- > > > > > >release.md > > > > > > > > > > > > PRs welcome! > > > > > > > > > > https://github.com/cordova/apache-blog-posts/pull/28 > > > > > > > > > > > > > > >
