software-mansion / react-native-screens

Native navigation primitives for your React Native app.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Missing React-RCTImage dependency

stianjensen opened this issue · comments

Description

When upgrading to react-native 0.73, I needed to upgrade react-native-screen to the latest version in order to make it build properly on Android.
Then I ran into an issue on iOS where React-RCTImage disappeared from the list of dependencies of RNScreens in Podfile.lock.

It looks like it stems from this commit, which first shipped with v3.26.0:
c3d1ae8

React-RCTImage is only added to the list of dependencies if you're running in a react-native environment without install_modules_dependencies.

The error I was getting was:

ld: Undefined symbols:
  _OBJC_CLASS_$_RCTImageLoader, referenced from:
       in RNSScreenStackHeaderConfig.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Patching the podspec locally to add back React-RCTImage (at least when running with new_arch_enabled == false, the only config I've tested so far), resolves the issue for me. Has it gotten lost in this case accidentally?

I can see from the PRs to the example repo here as well that the dep got lost when updating the version of react-native-screens used in the example repositories:
#1979

For context, I am running with use_frameworks! in my Podfile, but have seen no issues with that and react-native-screens until now.

Would it be possible to keep the dependency and thereby continue supporting this workflow?

Steps to reproduce

Install with use_frameworks! in your podfile, and then try to run on iOS.

Snack or a link to a repository

https://github.com/stianjensen/react-native-screens-test/tree/main

Screens version

3.29.0

React Native version

0.73.0

Platforms

iOS

JavaScript runtime

Hermes

Workflow

React Native (without Expo)

Architecture

Paper (Old Architecture)

Build type

Debug mode

Device

iOS simulator

Device model

No response

Acknowledgements

Yes

Yeah, this is rather unintended. Thanks for letting us know.

Most likely we will bring back react-image to our dependency list, as we directly consume it.