Use android artifacts for react-native libraries in react-native-bridge

[oguzkocer]

What?

This PR updates the react-native-editor, react-native-aztec & react-native-bridge projects to use the published artifacts of react-native & react-native libraries such as react-native-svg.

Why?

This is done to simplify these 3 projects and more importantly so that we don't have to maintain forks for them. This change will be followed up with #39348 which will drop these forks and use the original repos instead.

How?

We already had a setup for using these published artifacts in these projects. This was used when we were publishing react-native-bridge & react-native-aztec projects themselves. So, we just needed to remove the setup for using the source code for these libraries.

Testing Instructions

We should verify that both react-native-editor demo project and WordPress-Android work as expected. There isn't a specific change in this PR, so we'll need to make due with smoke tests.

[fluiddot]

@oguzkocer I think this PR is ready for review, wdyt?

[fluiddot]

We should add the case of parsing regular version values (i.e. x.y.z). This is not an issue yet because this code actually works (the result of dep.lastIndexOf('#') is -1) but I don't think it's a reliable approach.

[fluiddot]

One caveat to take into account is that due to this change, we'll no longer be able to modify the source code of the dependencies when testing locally, as now they'll be read-only. I don't think this is a major issue, but it might affect the development workflow when working on patching for a dependency. As a workaround for this, we could modify locally the following files in case we'd like to modify a dependency (e.g. react-native-video):

packages/react-native-editor/android/settings.gradle:

include ':react-native-video'
project(':react-native-video').projectDir = new File(rootProject.projectDir, '../../../node_modules/react-native-video/android-exoplayer')

packages/react-native-editor/android/app/build.gradle:

// implementation "com.github.wordpress-mobile:react-native-video:${extractPackageVersion('../../../react-native-editor/package.json', 'react-native-video', 'dependencies')}"
api project(':react-native-video')

[fluiddot]

Now that we won't use this argument, we could also remove it from this script in GB-mobile.

[oguzkocer]

We can do this in a follow up PR since passing the property is harmless.

[oguzkocer]

As a workaround for this, we could modify locally the following files in case we'd like to modify a dependency (e.g. react-native-video):

@fluiddot I am not sure I fully understand your suggestion. Are you saying you'd like to keep a commented out code in the repo so it can be used for testing? If that's the case, as a rule of thumb, we typically prefer not to have any commented out code in our repository. We believe git history should be the way to go for anything we might want to revert back and for anything else, we try for a more elegant solution depending on the problem.

My preference would be to not have anything like this in the project and use the proper way to test it by publishing the necessary version from the publisher library and updating the version. The main reason for this is that building from source code might introduce side effects to the project and might even fail because of the configuration of react-native-bridge. This could happen even if using the artifact directly works as expected which can lead a developer into wasting time debugging something unnecessary. For anyone who is familiar enough with Gradle and understand these typical issues, even without the commented out code, it's easy enough to use the source code for a quick testing, so the option will still be there, it just won't be promoted for everyone.

Let me know what you think!

[fluiddot]

As a workaround for this, we could modify locally the following files in case we'd like to modify a dependency (e.g. react-native-video):

@fluiddot I am not sure I fully understand your suggestion. Are you saying you'd like to keep a commented out code in the repo so it can be used for testing? If that's the case, as a rule of thumb, we typically prefer not to have any commented out code in our repository. We believe git history should be the way to go for anything we might want to revert back and for anything else, we try for a more elegant solution depending on the problem.

My preference would be to not have anything like this in the project and use the proper way to test it by publishing the necessary version from the publisher library and updating the version. The main reason for this is that building from source code might introduce side effects to the project and might even fail because of the configuration of react-native-bridge. This could happen even if using the artifact directly works as expected which can lead a developer into wasting time debugging something unnecessary. For anyone who is familiar enough with Gradle and understand these typical issues, even without the commented out code, it's easy enough to use the source code for a quick testing, so the option will still be there, it just won't be promoted for everyone.

Let me know what you think!

@oguzkocer I totally agree with your opinion, in fact, the code I provided was just an example of how we could test using the source code of a library, I didn’t want to imply that it was a suggestion to include in the PR, sorry for the confusion.

[fluiddot]

@fluiddot I've addressed your feedback & comment. I am going to leave it unmerged to give you a chance to check it out. Feel free to merge it at your convenience.

@oguzkocer The PR is ready to merge, however, I'll wait until a fixed is provided to address the failure in CI job End-to-End Tests / Admin - 2 (pull_request), since is a required PR check for merging. Btw, this failure is unrelated to the changes of this PR.

[oguzkocer]

@fluiddot I restarted the CI job and it succeeded this time. As you mentioned, there aren't any changes related to that job in this PR, so I think it's safe to merge, which I'll do so now.