On Mon, Jan 12, 2015 at 6:57 PM, Steven Gill <[email protected]> wrote:
> 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 <[email protected]> > 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 > The thing that is a hiccup for me is that this would leave the ./bin/create flow in a crippled state, unless we can figure out how to get ./bin/create to have the plugin added by default. I think the best first step towards ripping it out is removing all non-critical functionality from it. e.g. key events could be made into an optional plugin rather than included in core. Would also make the documentation for key events nicer... http://cordova.apache.org/docs/en/4.0.0/cordova_events_events.md.html#Events > > > > 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." > E.g. for non-browserify flow: grunt compile:android --android-platform=path/to/cordova-android For browserify flow, you'll have to tell browserify where the platform JS is at prepare time, so we'll need to ensure the create script stashes it somewhere (e.g. platforms/android/platform_modules) Note: chose name platform_modules as a peer to platform_www, which is used by prepare to know where cordova.js is... although come to think of it, we can likely delete platform_www when using browserify. > 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? > Very true. #2 sounds easiest. Can even feature-detect via an existence check for platforms/FOO/platform_modules > > I will whip this into a proposal soon so we can all review it and create > issues once we finalize the design. > Awesome! > > > > > > > > On Fri, Jan 9, 2015 at 5:58 PM, Steven Gill <[email protected]> > > 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 <[email protected]> > > > wrote: > > > > > > > On Fri, Jan 9, 2015 at 2:26 PM, Steven Gill <[email protected]> > > > > 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 <[email protected] > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
