Add gradle plugin and androidX versions into project-level gradle

[SaeedZhiany]

Introduction

Hi, everybody,
I come from a discussion from here.
The discussion briefly is about how we should handle the version of androidX packages used by RN libraries from main project gradle file in a consistency way.

The Core of It

The main problem before RN 0.60.x is that RN library developers using his/her preferred gradle plugin version within their libraries without any attention to main project gradle plugin version. also, due to inactivity of its maintainer, there are lots of RN libraries that not using latest gradle plugin and even sending PR to upgrade the version doesn't help due to lack of PR reviews by the maintainers. so it causes some sort of problems in building android project due to multiple gradle plugin version used in the process. so CI servers usually fail in the building (and in my case, I can't automate my release building)
some workaround for the issue (that I currently use it) is writing a script that reads main project's gradle plugin version and replaces the versions in the libraries' gradle files to make all the libraries compatible with the main project. to be honest I don't like such patchy works. I like to solve problems from their root.

Recently, androidX support has been added to RN and library developers has begun to migrate their libraries to using androidX instead of support libraries. react-native doesn't include androidX packages' version into gradle file, so I think the second wave of nightmares(!!!) will come shortly.

Each developer has own strategy to migrate.

1. Some of them use a fix version number just like to gradle plugin version and obviously, it has
   the same problem as a result.

2. The others assume that an extra property is defined in project-level gradle with a name that their library is using.
   although this is a better way compared to the first one, it has another problem. due to the lacking naming convention, every developer can assume their pattern for the name of androidX packages within ext. as an example for androidX's annotation package, developer A assumes an extra property with the name androidXAnnotation and developer B can assume androidX_annotation and so on.)

So I start this discussion to make a general solution that avoids patchy workarounds and solve the mentioned issues in a more precise way.

solution for gradle plugin version
I currently submit a PR for android gradle plugin issue here but unfortunately, it does not even receive a precise review yet, only one opposition that can not convince me why my proposed solution isn't correct.

solution for androidX package's version
This is just an idea in my mind from discussing with @mikehardy, @matt-oakes, and @jdnichollsc, (it's would so good if you take a time to read the discussion)

I know androidX packages are separately maintained and have their versioning scheme that is not necessarily the same among the packages so having lots of properties within the main project gradle file seems not a good solution.
So I'm thinking about having a separated RN project-level file in for specifying the packages' version, then somehow importing them in project-level gradle as extra properties using gradle commands. I don't much familiar with gradle system and groovy language so I couldn't submit a PR for that. is anybody can confirm if is it possible to do such thing at all? and if yes, how we can achieve that.

Discussion points

• I like to reach a naming convention about androidX packages so RN library developers can rely on that to import and use the packages' version in their libraries in a consistent way with the other libs used in an RN project.

• Also, Finding a solution to make RN libraries automatically use project-level gradle plugin version.

The sooner the better, because I think the more time passes, the harder it becomes to solve these problems.

[mikehardy]

Useful discussion I think

Do we need to specify these version?

Per the linked discussion, I'm not aware of a solution that currently meets all use cases and is better than specifying library-specific versions in a gradle-consumable way, somehow. We're currently using android/build.gradle::ext{} scope variables for that in projects, and it works okay.

Where to specify the versions if we need to specify them?

The list of library versions specified in that threatens to grow yes, but I admit I like simple solutions. I see no reason to have what appears to me to be an extra complication of another file, and an import mechanism. The android/build.gradle file is not very large, it is already under edit sometimes, it is known, and the ext{} block is pretty easy to handle. So I'd just keep it there.

What naming convention if we need to specify versions?

I'd love to have a naming convention though. I propose just using lower-case-first / camel-case / +Version for names. So if you needed the androidx.appcompat:appcompat dependency, you'd specify appcompatVersion. For androidx.vectordrawable, you'd specify vectordrawableVersion etc. Maybe this sucks? The important thing is to agree :-), propose something better as a convention formula and we can go with it.

Can we centralize the gradle versions?

I also like the idea of the gradle plugin version itself specified. I hate building my project on a new machine where it downloads 10 different gradle versions. For truly poorly maintained repos, the solution is to not use the repo. That's harsh but it's open source. Fork the thing and maintain it. Alternatively use patch-package, or don't use it. But even well-maintained packages skew between patch versions of gradle and harmony would be nice. So I'd like to see a gradle version specified in a single location if possible as well.

[SaeedZhiany]

I see no reason to have what appears to me to be an extra complication of another file, and an import mechanism. The android/build.gradle file is not very large, it is already under edit sometimes, it is known, and the ext{} block is pretty easy to handle. So I'd just keep it there.

I also like to keep them just in gradle file, my idea is changed because of what @matt-oakes said in this comment

[jdnichollsc]

Hello guys, this is my proposal https://github.com/proyecto26/react-native-inappbrowser/pull/97/files#diff-7ae5a9093507568eabbf35c3b0665732

So we can have a configuration like this from our projects:
android/build.gradle

buildscript {
    ext {
        buildToolsVersion = "28.0.3"
        minSdkVersion = 16
        compileSdkVersion = 28
        targetSdkVersion = 28
        supportLibVersion = "28.0.0"
        androidXVersion = "1.+" // Default version for AndroidX dependencies
        androidXAnnotation = "1.1.0"
        androidXBrowser = "1.0.0"
       // Put here other androidX dependencies
    }

Let me know what you think 👍

[SaeedZhiany]

Thank you for your contributions and this is my opinion about your proposal.

[matt-oakes]

I've added this to the other PR, but I thought it best to post here too.

I still think having dynamic versions in the library and letting Gradle resolve them as needed is the best solution. I get that non-determinism is an issue, but why not use the same tactic as Yarn and NPM and enable locking? Documentation for Gradle dependency locking is here:

https://docs.gradle.org/current/userguide/dependency_locking.html

[mikehardy]

I could see that working technically

So there would be a new file with state https://docs.gradle.org/current/userguide/dependency_locking.html#lock_state_location_and_format

...requiring folks to manage that after adding locking directives to the gradles. I'm not excited about externalizing state personally but that's clearly a solution many like via social proof of package-lock/yarn-lock/Podfile.lock and as dependencies chain I can see why

I have not experienced anyone using this in pure native Android land (maybe it's just new to me though?) so I'm curious if culturally and documentation wise we'd be breaking trail.

Would this still handle the case where you could work with either version 28 of support or e.g. 1.0.x of some androidx lib? And maybe need to substitute the name? Or is this just a clean androidx future?

[jdnichollsc]

Hey guys, check an example of the new installation steps from the last version of my plugin https://github.com/proyecto26/react-native-inappbrowser#mostly-automatic-installation

[SaeedZhiany]

For the Android Gradle Plugin issue, @dulmandakh has a different solution. he proposed his solution with a few PRs in the repositories below that can be used as samples to other maintainers to change their libraries.

• oblador/react-native-keychain#227

• react-native-community/async-storage#207

• FormidableLabs/react-native-app-auth#381

@brodybits, please take a look at those PRs, if you find them useful, maybe it's better to start changing your template.

cc
@mikehardy, @matt-oakes, @jdnichollsc