feat: ship codegen-generated specs
Summary
So far with the new architecture-supported templates, we've been generating libraries that didn't ship their codegen-generated specs. This means the library's users had to build the codegen specs on their end (this was done implicitly). With this, the codegen-generated specs are generated at the build time and they are shipped with the library.
I've followed this guide from the React Native new arch working group.
Making sure example app builds are triggering codegen
An important problem to figure out was to make sure the codegen-generated specs were being built with each native build of the example app. To do that,create-react-native-library now modifies non-legacy example apps and adds:
- A new task to
example/android/build.gradlethat's triggered before each native build. - A prebuild action to the XCode build schema.
- A
pre_installhook toexample/ios/Podfilethat's triggered when user callspod install.
These modifications make sure yarn codegen is called on the repo root to generate the codegen specs.
Notes
- There is an important problem with React Native itself right now. When
react-native codegenis called, the generated Java code doesn't follow thecodegenConfig.android.javaPackageNameproperty in thepackage.json. This means the generated Java files are stored in a default location with the wrong package name. To fix it, I've added a script that moves the codegen-generated files into the correct place.
Test plan
Test if Android builds trigger codegen
- Create a non-legacy library using
create-react-native-library - Install the dependencies and build the example app on Android
- Make sure the build passes, and there are files under
android/generated.
Test if installing pods triggers codegen
- Create a non-legacy library using
create-react-native-library - Install the dependencies and run
pod installinexample/ios - Make sure the pods are installed and there are files under
ios/generated.
Test if iOS builds trigger codegen
- Create a non-legacy library using
create-react-native-library - Install the dependencies and run
pod installinexample/ios - Remove the codegen generated code from
ios/generatedsince that's generated by the pod install step - Build the app for iOS
- Make sure there are files in
ios/generated.
Test if building the library triggers codegen
- Run
yarn prepareto emulate the library release process - Run
yarn pack - Extract the files from the generated
package.tgz - Make sure there are files under
ios/generated, andandroid/generatedin the generated package.
move the codegen script and codegen patching into bob.
So far with the new architecture-supported templates, we've been generating libraries that didn't ship their codegen-generated specs. This means the library's users had to build the codegen specs on their end (this was done implicitly). With this, the codegen-generated specs are generated at the build time and they are shipped with the library.
I think it would be great to explain the advantages (or disadvantages) of this approach. My understand for example if you want to make android side work with old arch, the codgen generated interfaces, delegates can be usefull to be shipped with the project.