fix: stop an app's codegenConfig from hijacking this library's codegen - #201
Merged
Merged
Conversation
floyd-soomgo
force-pushed
the
refactor/flatten-android-gradle-module
branch
from
September 17, 2026 11:52
34d9cf5 to
727b3b5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When an app adds a TurboModule of its own and puts
codegenConfigin its root package.json, that config is applied to this library's codegen instead of the library's own.NativeCodePushSpecis never generated, the app's spec is written into the library's build directory, and compilation fails:The react-native gradle plugin's
findPackageJsonFile()looks for../package.jsonnext to the gradle module first and falls back to the app root when that file is missing. This library's module sat atandroid/app, so the first lookup never resolved and the app root was always read. It only stayed invisible while apps had nocodegenConfigof their own.Fix
The gradle module now lives at
android/. The first lookup resolves to the library's own package.json, which already carries the correctcodegenConfig. No second copy of the config is introduced, and this is the layout most React Native libraries already use.A separate commit removes the standalone gradle setup, which had stopped working long ago: the wrapper pinned Gradle 2.4, the buildscript classpath pinned AGP 1.3.0,
gradle.propertieswas in a subproject directory where Gradle never reads it, and Android unit tests run through an example app. None of those files were reachable from any build.Upgrading
An existing app holds an autolinking cache pointing at the old path, so the first build after upgrading fails:
Deleting these two directories clears it:
Nothing else changes for consumers. The gradle project name stays
:bravemobile_react-native-code-pushbecause it is derived from the npm package name, and the apply path forcodepush-export.gradleis untouched.Verification
codegen, Java compilation, unit tests and the CMake native build all pass on the RN 0.77.3, 0.80.3, 0.83.2 and 0.86.0 example apps, covering both ends of the supported range.
The reproduction case was checked on the lowest and highest versions: with
codegenConfigpresent in the app root,NativeCodePushSpec.javais generated for the library and the app's own spec is generated for the app module, each in its own place.