Add setup-nightly script for 3rd party libs to test nightly builds

[Kudo]

Summary

Most third-party libraries used to deal with react-native breaking changes by checking the package version, e.g. expo or reanimated. However, the nightly build version on npm is something like 0.0.0-20221001-2020-436362670. If we check the version, that would be the oldest version.

I've tried to visit some proper solutions. If we try to publish nightly versions as 0.999.0 or even 1000.999.0. That would be strange because there're newer published versions on npm than release versions. Maybe the current state to keep the 0.0.0 as nightly builds would still be a good idea. As a workaround, this PR tries to add the setup-nightly.js postinstall script. It will rewrite the version after installing the package:

• Rewrite version in package.json as 999.999.999
• Rewrite VERSION_NAME in ReactAndroid/gradle.properties as 999.999.999

Changelog

[General] [Fixed] - Fix nightly builds break version detection for third-party libraries

Test Plan

Test install local pakcage

1. cd /path/to/react-native ; npm pack --pack-destination $HOME
2. cd /path/to/app ; yarn add file:$HOME/react-native-1000.0.0.tgz
   check whether the versions in pacakge.json and gradle.properties are 999.999.999
3. test build and launch both on android and ios

Publish nightly build

I didn't test the publishing workflow. Maybe we should check whether CI results.

[github-actions]

	Warnings
⚠️	🔒 package.json - Changes were made to package.json. This will require a manual import by a Facebook employee.

Generated by 🚫 dangerJS against c4349b1

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	7,736,984	+0
android	hermes	armeabi-v7a	7,141,805	+0
android	hermes	x86	8,046,372	+0
android	hermes	x86_64	8,018,597	+0
android	jsc	arm64-v8a	9,605,087	+0
android	jsc	armeabi-v7a	8,372,677	+0
android	jsc	x86	9,551,020	+0
android	jsc	x86_64	10,144,034	+0

Base commit: 4363626
Branch: main

[cortinico]

Can you elaborate on what are the 3rd party lib assumptions you refer to here?

// Version for nightly build. Since third party libraries used to check the minor version for feature detections.
// The nightly build version we published to npm is `0.0.0` which will break third party libraries assumption

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: 403fea2
Branch: main

[Kudo]

Can you elaborate on what are the 3rd party lib assumptions you refer to here?

for instance,

• to support 0.69 libfolly_runtime.so breaking change, we have these linking code based on versions: https://github.com/expo/expo/blob/f2b83416fd7bdf6cee98c7815cf29c32fa5577eb/packages/expo-modules-core/android/CMakeLists.txt#L133-L147
• reanimated also has some code based on versions: https://github.com/software-mansion/react-native-reanimated/blob/1fcf2e288f5236bb2cdd340c51b1c801ecd9e6f8/ios/native/REAInitializer.mm#L42-L47

if you need more examples, please let me know. i'll try to find more for you. thanks!

[cortinico]

if you need more examples, please let me know. i'll try to find more for you. thanks!

It seems that both Expo and Reanimated rely on the VERSION_NAME inside ReactAndroid/gradle.propreties:
https://cs.github.com/expo/expo/blob/f2b83416fd7bdf6cee98c7815cf29c32fa5577eb/packages/expo-modules-core/android/build.gradle#L76

IMHO this should not be fixed by a version change inside React Native but by a version parsing change on your end. You can easily do something like:

def REACT_NATIVE_IS_NIGHTLY = reactProperties.getProperty("VERSION_NAME").startsWith("0.0.0")

You can then pass over this information to your Gradle/CMake config and use it accordingly. Or you can override your REACT_NATIVE_TARGET_VERSION to the upcoming stable (71) if IS_NIGHTLY is true.

I would refrain from:

1. Having a post-install script as that could expose us to security implications. Especially in this case the post-install script is only on nightlies and hard to spot as we're effectively manipulating the package.json which is something we should look into moving away from.
2. Tweaking the version number as that might have unexpected side effects. Eg. if a user tries to ./gradlew :ReactAndroid:publishToMavenLocal, they will be publishing 999. to their Maven Local. This version might will affect their local build for future RN projects (as it's higher than 0.x).

EDIT: Typo

[Kudo]

IMHO this should not be fixed by a version change inside React Native but by a version parsing change on your end. You can easily do something like:

def REACT_NATIVE_IS_NIGHTLY = reactProperties.getProperty("VERSION_NAME").startsWith("0.0.0")

this is fair enough to me. however, it needs third party libraries to update their build settings. i will start this change from expo and share how to integrate nightly testing to the community.
i'm closing the pr. thanks @cortinico!

[cortinico]

this is fair enough to me. however, it needs third party libraries to update their build settings. i will start this change from expo and share how to integrate nightly testing to the community.

I understand. Still third party libraries should not need to know the RN minor version. I can understand that Expo and Reanimated are edge case in this sense and might need specific APIs.

Still, I'm happy to discuss how we can expose APIs from the framework in a more structured way instead of relying on string comparisons on the version number 👍

[Kudo]

Still, I'm happy to discuss how we can expose APIs from the framework in a more structured way instead of relying on string comparisons on the version number 👍

thanks for the kindness. i would say the version detection so far is the reliable way. there are various types of breaking changes, i don't think we have to pay effort on exposing stable API in the meantime.

• for cpp file movement, we could add more build settings like adding more header search paths
• however, for java class renaming. the only way is based on version detection.

let's just keep it as-is.
there are still other issues from nightly build. i will create another pr to address them.

[Kudo]

there are still other issues from nightly build. i will create another pr to address them.

the pr is at #34846