Scaffold Gradle Wrapper differenly

Describe the Feature

I'm not sure how to name this feature, but I just wanted to share my thoughts on a problem which is affecting the CLI and can improve the developer experience somehow. Happy to collect opinion.

The current situation is that we have the following files committed in the new app template and in every project of users:

android/gradle/wrapper/gradle-wrapper.jar
android/gradle/wrapper/gradle-wrapper.properties
android/gradlew
android/gradlew.bat

Those files are The Gradle Wrapper, essentially scripts that download and execute the correct Gradle version.

The problem is that those files are committed in the repo of users, and create noise in the upgrade helper. For example: https://react-native-community.github.io/upgrade-helper/?from=0.67.5&to=0.68.6

With the upcoming version of React Native, we'll be having similar problems as the version of Gradle got updated and the Gradle Wrapper was also updated.

Binary files 0.71.1/RNDiffProj/android/gradle/wrapper/gradle-wrapper.jar and nightly/RNDiffProj/android/gradle/wrapper/gradle-wrapper.jar differ
diff --color -r 0.71.1/RNDiffProj/android/gradle/wrapper/gradle-wrapper.properties nightly/RNDiffProj/android/gradle/wrapper/gradle-wrapper.properties
3c3
< distributionUrl=https\://services.gradle.org/distributions/gradle-7.5.1-all.zip
---
> distributionUrl=https\://services.gradle.org/distributions/gradle-7.6-bin.zip
diff --color -r 0.71.1/RNDiffProj/android/gradlew nightly/RNDiffProj/android/gradlew
207a208,213
> # Stop when "xargs" is not available.
> if ! command -v xargs >/dev/null 2>&1
> then
>     die "xargs is not available"
> fi
>
diff --color -r 0.71.1/RNDiffProj/android/gradlew.bat nightly/RNDiffProj/android/gradlew.bat
17c17
< @if "%DEBUG%" == "" @echo off
---
> @if "%DEBUG%"=="" @echo off
28c28
< if "%DIRNAME%" == "" set DIRNAME=.
---
> if "%DIRNAME%"=="" set DIRNAME=.
43c43
< if "%ERRORLEVEL%" == "0" goto execute
---
> if %ERRORLEVEL% equ 0 goto execute
78c78
< if "%ERRORLEVEL%"=="0" goto mainEnd
---
> if %ERRORLEVEL% equ 0 goto mainEnd
83,84c83,86
< if  not "" == "%GRADLE_EXIT_CONSOLE%" exit 1
< exit /b 1
---
> set EXIT_CODE=%ERRORLEVEL%
> if %EXIT_CODE% equ 0 set EXIT_CODE=1
> if not ""=="%GRADLE_EXIT_CONSOLE%" exit %EXIT_CODE%
> exit /b %EXIT_CODE%

The problem is that we can't expect users to go inside the ./gradlew.bat (which is a Windows only file) to replicate the changes that the Gradle Wrapper brings over.

The problems are the following:

1. android/gradle/wrapper/gradle-wrapper.properties this is probably the only file we want to commit (if any) as it contains the Gradle version.
2. android/gradle/wrapper/gradle-wrapper.jar this is a binary file. We can't expect users to go to the react-native repo to download the corresponding binary
3. android/gradlew this is a bash script that has to be updated.
4. android/gradlew.bat this is a windows bat script that has to be updated.

Simple Implementation

The updates to those mentioned files can be achieved easily by the user if they run

cd android && ./gradlew wrapper --gradle-version=<VERSION> --distribution-type=all

So we could simply update the upgrade helper to:

1. Hide all the changes to the aformentioned files
2. Show a popup to run the command mentioned above (or have some sort of util inside the CLI that runs that).

Still users could miss the popup on top and never update their Gradle Wrapper version (which could cause build failures).

More complicated implementation

Potentially we can:

1. Ask the user to update only the android/gradle/wrapper/gradle-wrapper.properties
2. Hide the changes to gradlew, gradlew.bat, and gradle/wrapper/gradle-wrapper.jar from the upgrade helper.
3. Have checks on the run-android and build-android commands that check if the wrapper is up to date (i.e. by diffing the files against local versions of the wrapper), if not, run the command above that updates the wrapper for the user.

Start with the CLI upgrade helper and Android app template files: android/gradle/wrapper/gradle-wrapper.properties, gradle-wrapper.jar, gradlew, and gradlew.bat. Review the run-android and build-android entry points, then run the documented wrapper command to understand the current workflow. Done requires an agreed approach that keeps wrapper updates manageable for users without creating upgrade-helper noise.