Android backwards compatibility includeCodegenArtifacts statement

[Zach-Dean-Attractions-io]

Hi,

I am trying to create a backwards compatible Turbo native module library.

In the documentation here: https://github.com/reactwg/react-native-new-architecture/blob/main/docs/backwards-compat-turbo-modules.md it states

Note

If you configure your library to include codegen artifacts, you'll get Android backwards compatibility FOR FREE. This is currently the recommended approach.

The following instructions are only for libraries that chose to rely on the app-level codegen.

Is this statement correct?

I have followed these steps:

1. Created a Turbo Native Module using the command npx create-react-native-library@latest TurboModuleLibrary, which exposes a multiply function as an example.
2. Confirmed the codegenConfig specifies "includesGeneratedCode": true
3. Built and published the library to a local npm registry npm publish --registry http://localhost:4873/
4. Created a new React Native app running version 0.75.0 (where the legacy architecture will be in use) and installed the library npm install <library_name> --registry http://localhost:4873/
5. Included it into the App.tsx file:

import { multiply } from 'library_name'

//.. other code

<Text>Multiplication result: { multiply(4,5) }</Text>

6. Ran npx react-native run-android but it fails with the error

e: file:///.../library-name/android/src/main/java/com/myturbomodule/TurboModuleLibraryModule.kt:8:3 Unresolved reference: NativeTurboModuleLibrarySpec
e: file:///.../library-name/android/src/main/java/com/myturbomodule/TurboModuleLibraryModule.kt:10:3 'getName' overrides nothing
e: file:///.../library-name/android/src/main/java/com/myturbomodule/TurboModuleLibraryModule.kt:16:3 'multiply' overrides nothing
e: file:///.../library-name/android/src/main/java/com/myturbomodule/TurboModuleLibraryPackage.kt:12:55 Type mismatch: inferred type is TurboModuleLibraryModule but NativeModule? was expected

Granted I have not added the following into the build.gradle file but looking at the generated android code from codegen there is no newarch or oldarch directories.

+    sourceSets {
+        main {
+            if (isNewArchitectureEnabled()) {
+                java.srcDirs += ['src/newarch']
+            } else {
+                java.srcDirs += ['src/oldarch']
+            }
+        }

Is there something I'm missing or is this statement incorrect? The React Native documentation here: https://reactnative.dev/docs/the-new-architecture/codegen-cli also suggests the same in the Including Generated Code into Libraries section:

No need to include two sets of files to support both architectures on Android. You can only keep the New Architecture one, and it is guaranteed to be backwards compatible.

[Zach-Dean-Attractions-io]

I believe I've found the error. In the library project created by npx create-react-native-library@latest TurboModuleLibrary the file android/build.gradle contains the code

sourceSets {
    main {
      if (isNewArchitectureEnabled()) {
          java.srcDirs += [
            "generated/java",
            "generated/jni"
          ]
      }
    }
  }

And removing the if check for the new architecture solves the issue.

[Zach-Dean-Attractions-io]

Ah ok I am following now, I have been viewing it as a single dimension and just using 0.75.0 as my test version since it's the most recent version where the new architecture wasn't enabled by default. I didn't appreciate that library consumers might be using 0.78.0 and disabling the new architecture in favour of the legacy architecture.

I think the documentation could be clearer in that regard but it might also just be the way I was thinking about it was wrong. I think re-reading it now with the two dimension thinking it makes more sense.

I have another question then, if you don't mind. If we want our library, which will initially just be supporting the new architecture to be compatible with all React Native versions that could possible use the new architecture (0.68.0 onwards I believe) then we should probably disable shipping the generated code and instead rely upon the user running codegen so that it should work on their version of React Native? Or is it true that if I target the new architecture only and keep includesGeneratedCode: true it is guaranteed to work on any React Native version so long as it is using the new architecture and I may only run into issues when the legacy architecture is used?

[cortinico]

which will initially just be supporting the new architecture to be compatible with all React Native versions that could possible use the new architecture (0.68.0 onwards I believe)

In general, we don't recommend to support NewArch down to 0.68 because a lot of things have changed since then. I would recommend you support 0.76+ which is when NewArch became the default.

then we should probably disable shipping the generated code and instead rely upon the user running codegen so that it should work on their version of React Native?

It's not as simple sadly. The problem is that on top of what codegen generates, there is the native code of your library. For example codegen generate a Java abstract class that you need to implement.
Your implementation might contain code that is not compatible with other versions of RN because you use newer APIs.

On top of this, the codegen API shipped breaking changes (example: adding a parameter to a method you need to implement) between versions, so having includesGeneratedCode = false might actually result in your library not working because of this problem.

[Zach-Dean-Attractions-io]

Hi @cortinico

Thank you for that information, it's very useful.

I see in the react-native-svg project they have a list of supported versions of their library against the React Native version. This is probably a hard question for you to answer but is this typical for React Native libraries to do? For example if we ship version 1.0.0 of our library and it works for React Native 0.76.0 - 0.78.0, but then in version 0.79.0 of React Native there is some change and then version 1.0.1 of our library only works on 0.79.0 and above.

I guess I'm thinking about the scenario where we have version 1.0.0 of our library published and our client is using 0.78.0 of React Native. Then we release version 1.0.1 which requires React Native 0.79.0but for some reason the client is unable to upgrade.

Or even a scenario where a client isn't yet on version 0.76.0 of React Native and so can't consume our initial library.

I don't know how common these scenarios would be and maybe in the React Native world it is typical apps are kept up to date with the React Native version and so it is a non-issue.

Are there methodologies to handle these scenarios? I don't really see there being any besides building the library against the given version of React Native and publishing it. But, that's effort on our side developing the library against another version of React Native and not quite sure how we would publish it when we would want our 'main' code to be on the latest version.

Sorry for the strange question, but thought I'd ask in case you have any insight

[cortinico]

As you said, there is no right/wrong answer here. Some library release a version for every RN release. Other they just release a version whenever they wish and bump minor/major based on changes in their API.

What I believe is important, is having a table with supported RN version in your README so that users know which version of your library to use.

Users will use either Expo or other tools such as align-deps https://microsoft.github.io/rnx-kit/docs/tools/align-deps to keep deps aligned

[Zach-Dean-Attractions-io]

Thank you for guidance @cortinico, it is very much appreciated.