Add support for Gradle Configuration Cache

[pvegh]

Using Gradle 8.2 with stable config cache support, enabling it with org.gradle.configuration-cache=true I'm getting this error:

4 problems were found storing the configuration cache, 2 of which seem unique.
- Script '/Users/..../node_modules/@react-native-community/cli-platform-android/native_modules.gradle': external process started 'node -e try {console.log(require('@react-native-community/cli').bin);} catch (e) {console.log(require('react-native/cli').bin);}'
  See https://docs.gradle.org/8.2.1/userguide/configuration_cache.html#config_cache:requirements:external_processes

org.gradle.api.InvalidUserCodeException: Starting an external process 'node -e try {console.log(require('@react-native-community/cli').bin);} catch (e) {console.log(require('react-native/cli').bin);}' during configuration time is unsupported.
	at org.gradle.configurationcache.initialization.DefaultConfigurationCacheProblemsListener.onExternalProcessStarted(ConfigurationCacheProblemsListener.kt:117)
	at org.gradle.configurationcache.InstrumentedInputAccessListener.externalProcessStarted(InstrumentedInputAccessListener.kt:110)
	at org.gradle.internal.classpath.Instrumented.externalProcessStarted(Instrumented.java:501)

It would be nice to be able to use config cache

[cortinico]

Hey @pvegh Thanks for pointing this out,

Yes ideally we should be able to enable configuration caching for Gradle.

The problem is that at the same time we see a number of users interested in using pnpm or other tools that rely on invoking require.resolve() to resolve package locations (see https://github.com/facebook/react-native/pull/38702 cc @Esemesek).

Invoking those scripts at configuration time is letting configuration cache fail. We don't have a solution at the moment.

I recall brainstorming with this with both @byCedric and @tido64 in the past. We should invoke require.resolve() outside of the native build tool logic, have the resolution output stored on file, and let the native build tool consume that file with the paths. The CLI could play this role in invoking the first resolution.

Currently there is also a performance cost at build time as we invoke require.resolve() over and over whenever the app builds, while the path itself of a package is unlikely to change.

[pvegh]

What's strange is that I've been using config cache for a while with partial success with in this RN project. Had to workaround things sometimes but it worked most of the time. Now upgrading to Gradle 8.2, and CC being stable now, probably something changed, because now this error seems to be persistent. It was fun doing 1s deployments after minimal local changes in native code Maybe it's worth a new look into this, it being officially stable.

# old
org.gradle.unsafe.configuration-cache=true
# from gradle 8.1
#org.gradle.configuration-cache=true

[github-actions[bot]]

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

[pvegh]

Please consider this is a regression as it worked before, probably sometime before the 0.72 update. Looks like the support for pnpm broke config cache support, even if it wasn't official before.

Even a dirty workaround / opt-out of pnpm would be much appreciated. Our group doesn't need that tool daily/locally, probably there are others as well.

I was trying to do something like an if-else based on a gradle parameter which I'd set locally but failed because of some follow up problem and I had to consider it a wall because the company doesn't want me to spend time on it, which I try to respect but also know how much it slows my team down, so trying to at least help out here.

[cortinico]

There is an effort going on from @robhogan to address this so that Gradle configuration caching works well. We don't have an ETA at the moment though

[ahruss]

I opened a tiny PR that I think resolves the configuration cache error: https://github.com/react-native-community/cli/pull/2201

I frankly don't know enough about pnpm or whatever other tools you're referring to, but I think this change alone is enough to un-break configuration cache in the simple case, and I don't see how it would break integration with other tools, as it's pretty much equivalent to the existing behavior, just wrapped in constructs that Gradle understands how to track at configuration time.

Invoking those scripts at configuration time is letting configuration cache fail.

I don't think this is necessarily true -- you just have to wrap the invocations in the appropriate Gradle providers instead of directly calling them via Runtime.exec: https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:external_processes

[cortinico]

I don't think this is necessarily true -- you just have to wrap the invocations in the appropriate Gradle providers instead of directly calling them via Runtime.exec: docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:external_processes

The problem is that we need the output of an external command (node) as an input for other tasks which ends up breaking configuration cache.

Your PR https://github.com/react-native-community/cli/pull/2201 is valid, but it doesn't solve the whole Configuration Caching problem we do have inside react-native-gradle-plugin

[city0666]

Starting an external process 'node -e try {console.log(require('@react-native-community/cli').bin);} catch (e) {console.log(require('react-native/cli').bin);}' during configuration time is unsupported. Starting an external process 'node /Volumes/Backup/Mobile/Vision-main/node_modules/@react-native-community/cli/build/bin.js config' during configuration time is unsupported.

• Try:

Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. Get more help at https://help.gradle.org.

BUILD FAILED in 7s 25 actionable tasks: 11 executed, 14 up-to-date Configuration cache entry discarded with 4 problems.

How to fix this issue 0.73.4

[github-actions[bot]]

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

[pvegh]

I would like this not to get closed but improved soonish, since it's the reason currently for 30s configurations even if otherwise not necessary with enabled config cache.

[szymonrybczak]

Let's move this issue under https://github.com/facebook/react-native/issues as autolinking dependencies was moved into React Native Core. Thank you @pvegh for all support :pray:

[pvdmde]

I copy pasted the content there. Do you think that's ok? https://github.com/facebook/react-native/issues/45154

[cortinico]

Small heads up taht this is coming in the next RN release:

• https://github.com/facebook/react-native/pull/49484