How to handle AndroidX conversion in libraries, with react-native 0.60

[mikehardy]

There has been some discussion on Discord about how to support react-native-community module consumers on both sides of the AndroidX divide in the transition from react-native 0.59 to 0.60

The general problem is that react-native native modules are included in the Android build system as source generally, and all the Java source in a project must be using either AndroidX or the support libraries, but they may not mix.

So if a module converts to AndroidX and distributes as source, the only way to use the module in your project is to convert your project to AndroidX. It is reasonable to assume there are projects that either cannot do this, or cannot do it immediately, implying that we will be stranding those projects on old module versions for any module that converts to AndroidX.

I do not believe there has been consensus on how to support non-AndroidX and AndroidX projects at the same time, but the ideas I have seen so far are:

• convert module to AndroidX, then use some tool (bob?) to generate AAR for distribution and run reverse jetifier
• maintain module with support libraries and distribute as AAR so consumers may use Jetifier
• have a postinstall script that does a translation using something like this https://developer.android.com/topic/libraries/support-library/downloads/androidx-class-mapping.csv
• maintain separate branches (tagged @androidx or @support or similar)

I'm interested in the AAR ideas but I'm unsure of the exact mechanics to generate an AAR, distribute it, and how to document AAR integration into a project.

[mikehardy]

Closing in preference to react-native-community/discussions-and-proposals#129