Repository navigation
Add support for Gradle Configuration Cache #2058
Description
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
Activity
cortinico commentedon Aug 17, 2023
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
pnpmor other tools that rely on invokingrequire.resolve()to resolve package locations (see react/react-native#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.[-]Add support for Gradle Config Cache[/-][+]Add support for Gradle Configuration Cache[/+]pvegh commentedon Aug 17, 2023
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.
github-actions commentedon Nov 16, 2023
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 commentedon Nov 18, 2023
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 commentedon Nov 22, 2023
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 commentedon Dec 11, 2023
I opened a tiny PR that I think resolves the configuration cache error: #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.
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 commentedon Dec 12, 2023
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 #2201 is valid, but it doesn't solve the whole Configuration Caching problem we do have inside
react-native-gradle-plugincity0666 commentedon Feb 22, 2024
github-actions commentedon May 24, 2024
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 commentedon May 26, 2024
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 commentedon Jun 24, 2024
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 🙏
pvdmde commentedon Jun 25, 2024
I copy pasted the content there. Do you think that's ok?
react/react-native#45154
cortinico commentedon Feb 17, 2025
Small heads up taht this is coming in the next RN release: