Codegen and Libraries which are not inside node_modules

[satya164]

Hey folks, I have been working on a template for using Turbo modules with create-react-native-library.

The generated project includes an example app which allows testing the library during development. The structure looks like this:

library
  src (JS code)
  android
  ios
  example (react native app which links to the library)

But I run into an issue with Codegen on iOS. If the library uses codegen, then this fails because the library isn't located inside example/node_modules where Codegen will look through to find the code.

Currently, I have this patch that reads react-native.config.js to see if there are any libraries that are going to be linked and includes them for codegen:

diff --git a/node_modules/react-native/scripts/generate-artifacts.js b/node_modules/react-native/scripts/generate-artifacts.js
index d0d8a00..f0cc68d 100644
--- a/node_modules/react-native/scripts/generate-artifacts.js
+++ b/node_modules/react-native/scripts/generate-artifacts.js
@@ -121,6 +121,44 @@ function main(appRootDir, outputPath) {
       `\n\n[Codegen] >>>>> Searching for codegen-enabled libraries in ${confifDir}`,
     );

+    let rnConfig;
+
+    try {
+      rnConfig = require(path.join(appRootDir, 'react-native.config.js'));
+    } catch (e) {
+      // Ignore
+    }
+
+    if (rnConfig && rnConfig.dependencies) {
+      Object.keys(rnConfig.dependencies).forEach(name => {
+        const dependency = rnConfig.dependencies[name];
+
+        if (dependency.root) {
+          const configFilePath = path.join(
+            dependency.root,
+            CODEGEN_CONFIG_FILENAME,
+          );
+          if (fs.existsSync(configFilePath)) {
+            const configFile = JSON.parse(fs.readFileSync(configFilePath));
+            if (
+              configFile[CODEGEN_CONFIG_KEY] != null &&
+              configFile[CODEGEN_CONFIG_KEY].libraries != null
+            ) {
+              console.log(`[Codegen] Found ${name} in 'react-native-config.js'`);
+              configFile[CODEGEN_CONFIG_KEY].libraries.forEach(config => {
+                const libraryConfig = {
+                  library: { name, path: dependency.root },
+                  config,
+                  libraryPath: dependency.root,
+                };
+                libraries.push(libraryConfig);
+              });
+            }
+          }
+        }
+      });
+    }
+
     // Handle third-party libraries
     Object.keys(dependencies).forEach(dependency => {
       if (dependency === REACT_NATIVE_DEPENDENCY_NAME) {

Example react-native.config.js

const path = require('path');

module.exports = {
  dependencies: {
    'react-native-library-name': {
      root: path.join(__dirname, '..'),
    },
  },
};

Do you think it's possible to support including dependencies that are not in node_modules like it's possible with the old architecture?

[cortinico]

Do you think it's possible to support including dependencies that are not in node_modules like it's possible with the old architecture?

I'm not entirely sure if this issue falls between the domain of our codegen setup or the CLI.

For our setup, the generate-artifact.js script has a parameter that takes the path to your node_modules: https://github.com/facebook/react-native/blob/9214da12385fd88264ca5de3e5fdc78559ec3080/scripts/generate-artifacts.js#L41-L46

That would allow you to specify another node_modules folder. Still all the libraries should be located there. Also @cipolleschi will be able to help you further as he has more context than me on the iOS setup.

As for the CLI, you can open an issue here: https://github.com/react-native-community/cli

[satya164]

I'm not entirely sure if this issue falls between the domain of our codegen setup or the CLI.

Thanks! This is only an issue with codegen on iOS, I don't need any other changes apart from this patch (and react-native.config.js which is how it works with old architecture as well).

From my understanding since generate-artifacts.js is called here https://github.com/facebook/react-native/blob/9214da12385fd88264ca5de3e5fdc78559ec3080/scripts/cocoapods/codegen_utils.rb#L270, so it has to be addressed on React Native side.

[cipolleschi]

Hi @satya164, Thanks for looking into this. However I don't think we want to support that setup.

IIRC, in that setup you have an external module (the library) which is forced as a dependency manually adding a line like:
pod <your library>, path <path to the folder that contains the podspec>

This is a development setup, which I don't think we would want in production.

For that development purposes, I think that the best solution should be to consider the component as part of the Example app, like we do with the component of packages/rn-tester.
This is a set up that we actually already support in the generate-artifact-executor,js file. This function reads the libraries from the app configuration and generates the codegen.

My suggestion is to prepare the template with a copy of the codegenConfig field in the Example/package.json file so that the current setup is able to pick up the dependency.
What do you think?

[thymikee]

FYI, the RN CLI supports a case where the native library is extracted into a self-sustained folder:
https://github.com/react-native-community/cli/blob/9555545155b6874f39c9e4bea4d1abeeb31f605f/packages/cli-config/src/__tests__/index-test.ts#L234-L282
We don't have a story for native modules that are part of regular app/src/main setup, but this is also something that we could support

[cipolleschi]

I understand your point and your setup. I think it make sense... What I don't really like is that, in that setup, you have to define dependencies in two places:

1. in the Podfile, using the pod "MyLibrary", path => "../MyLibrary"
2. in the react-native.config.js.

The react-native.config.js is also something we don't ship with the template: adding it in a script would make the people wonder what's going on.

Any chance to use just the Podfile to learn about local dependencies? It will also give you the lib path directly, without the need to specify it.

[satya164]

@cipolleschi

What I don't really like is that, in that setup, you have to define dependencies in two places

I don't have to specify it in the Podfile, only in react-native.config.js. The part about adding the pod is taken care of by auto-linking by the CLI. There's no other setup needed to link the native code apart from adding to react-native.config.js - this is used by CLI for auto-linking on both iOS and Android. However, since codegen for iOS isn't handled via the CLI, this is the only part that doesn't work.

The react-native.config.js is also something we don't ship with the template: adding it in a script would make the people wonder what's going on.

I get not supporting react-native.config.js since it's the config for the CLI. I just did it this way in the patch since it was easiest for me. But maybe CLI can expose this information to Codegen some other way? cc @thymikee

Any chance to use just the Podfile to learn about local dependencies? It will also give you the lib path directly, without the need to specify it.

Maybe you could give an example/link to what you mean? I'm not super familiar with this.

Though Podfile is iOS only, the path still needs to be specified somewhere for Android. Since CLI supports react-native.config.js already for both Android & iOS, it seems like a good place, but if there are any other ways to do this in a cross-platform way then that's good too.

[cipolleschi]

Ok, in that case, it's fine. To recap:

• Android is already supporting that use case
• It is a development setup and...
• ... it is also a monorepo setup: there are users that connects native modules and native components
• can be well isolated in self documenting code.

Could you open a PR with the code, please?
Some pointers:

1. The code should go to scripts/codegen/generate-artifacts-executor.js
2. There are utility functions like extractLibrariesFromJSON that could help you.
3. Define a proper self-contained function, like we did here. Something like extractLibrariesFromReactNativeConfig
4. This code is tested. It would be nice to cover this use case as well. This is the point where we test the library extraction.

For any question, please ask! I would be super happy to help you! 😄

[satya164]

Thank you! I'll look into it soon.