Testing against multiple RN versions

[johnf]

What happened?

Apologies in advance; this is more a question than a bug report.

Should I be able to use this project to create a matrix test in GitHub actions to test my react native library against multiple versions of React Native?

I have the basics of this set up https://github.com/oblador/react-native-vector-icons/tree/monorepo

I'm using detox ti run e2e tests.

This works perfectly with RN 0.73

My intention was to then setup a matrix where I would

• yarn add react-native-test-app@0.72-stable (0.71-stable etc)
• yarn android
• detox ...

As I'm trying to get this working on past versions of RN I'm hitting all sorts of problems like

• Wrong gradle version
• Wrong java version
• Kotlin mismatches

I want to check if what I'm trying to do is feasible before filing more bugs around the issues I'm seeing.

Version

3.3.6

What platforms are you seeing this issue on?

• Android
• iOS
• macOS
• visionOS
• Windows

System Information

N/A at this stage

Steps to Reproduce

See https://github.com/oblador/react-native-vector-icons/tree/monorepo

Code of Conduct

• I agree to follow this project's Code of Conduct

[johnf]

I found one issue that I fixed in #1934 because I'm running a monorepo.

But I think that's only part of the puzzle.

I noticed test:matrix in RNTA makes a number of other changes to packages.json, going to look into that shortly

[kelset]

Hey @johnf - so, first off thanks for asking!

This is something that we have been thinking on how to make more easily accessible for a while - in particular for situations like BabylonReactNative (they are still migrating to it: BabylonJS/BabylonReactNative#641, but they need to test, similar to you, different RN versions).

As you already found out, we do have a few scripts in this repo to make the process of switching versions of RN for our local test bench swifter:

• https://github.com/microsoft/react-native-test-app/blob/trunk/scripts/test-e2e.mjs
• https://github.com/microsoft/react-native-test-app/blob/trunk/scripts/test-matrix.mjs
• https://github.com/microsoft/react-native-test-app/blob/trunk/scripts/set-react-version.mjs

So maybe an alternative is to tweak those scripts so that they can be more generalised and exported along with RNTA, so that you can just invoke them in a RNTA-based test app.

While that might be the future, let's try to focus on the here&now, going back to your specific plan: there are a couple things that I'd change. First off, unless I'm missing something, react-native-vector-icons is entirely missing an example app (at least in your monorepo branch). My first though is that, instead of trying to spin one up at runtime, you add a permanent one in your codebase (which should be relatively easy), and then just change the react-native version (and other settings) in that one. There's a guide on how to migrate an existing test app to RNTA here. (also, yarn add react-native-test-app@0.72-stable is not a valid command / doesn't do what I think you might think it does)

To move up/down the supported RN versions, the quickest way would be to simply change the RN version in the package.json of the test app. For situations where that's not enough, yarn configure-test-app is there to help. Here's a link to the wiki page with details about this.

So, to recap, what I would suggest you try out is to:

• add a permanent test app to the monorepo, maybe in a apps top level folder, or in the packages one as test-app (as we do in rnx-kit)
• in your CI script, set it up to change the RN version in the test app package.json
• for good measure, run yarn configure-test-app after that
• run your E2E tests

I think that should be enough for your user case - what do you think?

(PS: thanks for sending over the PR, I'll check it out next)

[johnf]

@kelset Thanks for the detailed response!

The test app location isn't super obvious. It's in packages/icon-explorer https://github.com/oblador/react-native-vector-icons/tree/monorepo/packages/icon-explorer

I've been working on an approach similar to what you outlined. The only piece I have missing is yarn configure-test-app. I completely missed that in the docs!

It's making changes that I've been playing with to try and get things working. I'll experiment with this later tonight. I suspect we'll still need a different approach, though, as I can see it's overwriting my changes to configure detox. I'm guessing it's just writing some of the files rather than programmatically changing the necessary bits.

Regarding your other question:

one small nit is that I'm not sure we'd recommend having multiple RNTA apps in the same codebase on different RN versions

In my case, it's not different apps causing the issue. Because RNVI is a library, the common package depends on RN. So when I change the RN version in the example app, multiple versions now exist. Not hoisting just the example app can help, but that other fix would still have been needed due to the way it traversed up the directory path.

[tido64]

In general, we don't recommend multiple versions of react-native within the same repository because hoisting may cause version mismatches, especially with Metro and bundling. That said, if you're especially careful, or if you're using pnpm, it might work just fine.

On the note of Gradle/Java mismatches, I have another PR that hopefully helps: #1935

With this, you shouldn't have to run yarn configure-test-app as often (or at all).

Regarding changing react-native versions: In addition to what kelset said, you can also look into align-deps if you're only dealing with stable releases. If you need to support release candidates and/or nightlies, there's currently no other way than our scripts.

[johnf]

@tido64 I normally don't strictly have different versions in the same repo, only at test time when I test against the different apps. This is an important use case to get right as it's a great use for this project. If you see what I'm trying to do with RNVI, I want to make sure that we are testing the library against

• Past versions of RN
• New arch and old arch
• Potentially even different Android API levels

Anyway, I've got this working (it still needs some work, but the RNTA part is happy on Android now). You can see my approach at https://github.com/oblador/react-native-vector-icons/blob/monorepo/packages/icon-explorer/set-rn-version.sh, which is basically what @kelset suggested.

I suspect I'll be able to move the Gradle bits once #1935 lands

If you ignore the Detox specific bit, align-deps does 99% of the work.

[tido64]

3.5.0 now automatically configures the Gradle wrapper. Let us know how it works for you.

For Babel config, have you tried @rnx-kit/babel-preset-metro-react-native? It picks @react-native/babel-preset if it finds the preset in the package.json, and falls back to metro-react-native-babel-preset otherwise.

As for Detox, you can probably write some logic in build.gradle to handle it instead. We do a similar thing here for androidx.appcompat:appcompat:

react-native-test-app/android/app/build.gradle

Lines 297 to 304 in ad49b91

	if (reactNativeVersion > 0 && reactNativeVersion < v(0, 68, 0)) {
	// androidx.appcompat:appcompat:1.4.0+ breaks TextInput. This was fixed
	// in react-native 0.68. For more details, see
	// https://github.com/facebook/react-native/issues/31572.
	implementation(["androidx.appcompat", "appcompat", "1.3.1"].join(":"))
	} else {
	implementation libraries.androidAppCompat
	}

[johnf]

@tido64 The @rnx-kit/babel-preset-metro-react-native and build.gradle suggestions worked well for me. Thanks!

The gradle wrapper updates not so much. Mainly because of the way configure-test-app works e.g. It overwrites the following

• build.gradle - so I lose my detox changes
• babel-config.js - I lose the @rnx preset change
• metro-config - I lose my yarn workspace watchFolders

So I've stuck with my own script for the gradle changes

Happy to explore some other ideas on how to solve the multi RN version test problem if you like

[tido64]

The gradle wrapper updates not so much. Mainly because of the way configure-test-app works e.g. It overwrites the following

Can you try without using configure-test-app. With the latest changes, you shouldn't have to use this any longer. It's mostly for "updating" an app that you've had for a long time and need to refresh.

[johnf]

Can you try without using configure-test-app. With the latest changes, you shouldn't have to use this any longer. It's mostly for "updating" an app that you've had for a long time and need to refresh.

Looking at #1935 it looks like that code you changed is only ever called from configure-test-app

[tido64]

Can you try without using configure-test-app. With the latest changes, you shouldn't have to use this any longer. It's mostly for "updating" an app that you've had for a long time and need to refresh.

Looking at #1935 it looks like that code you changed is only ever called from configure-test-app

It should run with react-native build-android and run-android. So you wouldn't necessarily see any changes right away.

[tido64]

@johnf, are you still seeing issues?

[johnf]

@tido64 I have it mostly working. Thanks. I'll reopen when I spend more time on it if I have more issues.