feat: Support autolinking C++ only TurboModules on Android

[atlj]

Summary:

#2296 adds support for auto-linking C++ turbo modules on Android. However, you would still need a build.gradle file for your module to be linked. This is for a couple of reasons:

1. If the module doesn't have a valid AndroidManifest.xml file or a bulid.gradle file, react-native config returns null. See the related line.
2. If your code doesn't have a valid packageName, react-native config returns null. We don't need the packageName property since C++ projects are included by their paths. See the related line.
3. The native-modules.gradle file tries to add your turbo module as a gradle dependency without checking if it's a valid gradle project. See the related line.
4. The generated PackageList.java file tries to include and initialize your turbo module as a Java class. See the related line.

This PR derives a property called isPureCxxDependency from a few factors:

1. The user should define cxxModuleCMakeListsModuleName as a truthy value in their configuration.
2. The user should define cxxModuleCMakeListsPath as a truthy value in their configuration.
3. The user should define cxxModuleHeaderName as a truthy value in their configuration.
4. The user shouldn't have a build.gradle file in their sourceDir (This is android/ by default) or its subdirectories.
5. The user shouldn't have a AndroidManifest.xml file in their sourceDir or its subdirectories.

If all these cases are met, the CLI outputs the isPureCxxDependency property as true. This in turn causes the native-modules.gradle file not to include this dependency in the generated PackageList.java file and the dependency isn't added as a gradle dependency to the app project.

Test Plan:

I have created a turbo module using create-react-native-library. Then I linked the CLI and tested the implementation. I've also added react-native-reanimated as a dependency to the project's example app to make sure this implementation doesn't break the existing support for turbo modules.

Checklist

• Documentation is up to date to reflect these changes.
• Follows commit message convention described in CONTRIBUTING.md

[cortinico]

Thanks for sending this over @atlj this is great!

platforms.android.cxxOnly

I think we should not add a new property, and instead adapt the logic to work on the existing properties:

  cxxModuleCMakeListsModuleName?: string | null;
  cxxModuleCMakeListsPath?: string | null;
  cxxModuleHeaderName?: string | null;

and remove the assumption that there needs to be a *Package file.

[atlj]

Hey @cortinico I've removed the property from the config. The CLI now treats a dependency that doesn't have a manifest or a build.gradle file (full details in the description) as a pure cxx dependency.

[cortinico]

Hey @cortinico I've removed the property from the config. The CLI now treats a dependency that doesn't have a manifest or a build.gradle file (full details in the description) as a pure cxx dependency.

Thanks for the sending this over. I'll try to review this in the next days. Just a heads up that things are slower than usual those days due to https://conf.react.dev/

[szymonrybczak]

LGTM! Thank you for contribution @atlj! 🚀

I gave it a shot inside example and it retrieves all values correctly 🙌

"android": {
  "sourceDir": "path/react-native-cxx-turbomodule/cpp",
  "packageImportPath": null,
  "packageInstance": null,
  "buildTypes": [],
  "libraryName": "RNCxxTurbomoduleSpec",
  "componentDescriptors": [],
  "cmakeListsPath": "path/react-native-cxx-turbomodule/cpp/build/generated/source/codegen/jni/CMakeLists.txt",
  "cxxModuleCMakeListsModuleName": "CxxTurbomodule",
  "cxxModuleCMakeListsPath": "path/react-native-cxx-turbomodule/cpp/CMakeLists.txt",
  "cxxModuleHeaderName": "CxxTurbomodule",
  "isPureCxxDependency": true
}

[cortinico]

Just a heads up that if we merge this, the same functionality needs to be backported here:
https://github.com/facebook/react-native/blob/main/packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/tasks/GenerateAutolinkingNewArchitecturesFileTask.kt

[thymikee]

@cortinico is there any design doc around autolinking in the core RN repo? Does it clash somehow with RNCCLI autolinking, doing redundant work, bailing out?

[thymikee]

@atlj thanks for sending this! We have some docs around autolinking in https://github.com/react-native-community/cli/blob/main/docs/autolinking.md which includes other cxx stuff. Would you mind extending the docs with isPureCxxDependency and how and when to use it from a user perspective?

[cortinico]

is there any design doc around autolinking in the core RN repo? Does it clash somehow with RNCCLI autolinking, doing redundant work, bailing out?

Nope I don't have a design doc sadly, but I just ported over all the code from native_modules.gradle inside RNGP.

We should update native_modules.gradle in the near future (i.e. sometime next week), and fire a warning as the template will be updated to don't include that file anymore (see facebook/react-native#44799 for more context).
Running config and parsing all the configuration will remain inside the CLI though.

[thymikee]

Thanks, that makes it clearer I think! So we keep autolinking until it's deployed in the core (0.75?) and once it has parity, we can start removing it from this codebase?

[cortinico]

Thanks, that makes it clearer I think! So we keep autolinking until it's deployed in the core (0.75?) and once it has parity, we can start removing it from this codebase?

We can keep it around, I was actually thinking about updating the native_modules.gradle file to just emit a warning in 0.75 so that users won't accidentally include both core + cli ones