When attempting to update to Expo SDK 26 with all documented steps, my project fails to run.
(From https://github.com/react-native-community/react-native-svg/issues/591).
Problem cause
The update to react-native
brings with it a potential new Error
case, triggered if two native components are registered with the same name using requireNativeComponent
.
Here, the example is between expo
and react-native-qrcode-svg
, but this would also be the case with any additional dependencies which require react-native-svg
. The internal version difference between 5.x and 6.x here of react-native-svg
is not the problem, it is that the library is separately downloaded as a requirement of each package and they run separately without determining if requireNativeComponent
had already been called with the same component name, "RNSVGPath"
.
"dependencies": {
...
"expo": "^26.0.0",
"react": "16.3.0-alpha.1",
"react-native":
"https://github.com/expo/react-native/archive/sdk-26.0.0.tar.gz",
"react-native-qrcode-svg": "^5.0.6"
...
}
As the two versions of react-native-svg
are specified internally by each dependency, this can’t be easily fixed in consuming projects.
Suggested action in the next Expo release
This incompatibility is crippling. I played with a fork of react-native-qrcode-svg
to verify both that matching the react-native-qrcode
dependency exactly in dependencies
and peerDependencies
did nothing to fix the issue.
What would work is if react-native-svg
were made into a peer dependency of expo
, which would require consuming projects to include a single version, thereby ensuring the side-effect is only run once. This would also require each other SVG package to list react-native-svg
in peerDependencies
- in the case of react-native-qrcode-svg
, this is already true. With the change to React Native around registering of native components, this may be a necessary pattern for similar shared UI libraries in future.
"dependencies": {
...
"expo": "^26.0.0",
"react-native-qrcode-svg": "^5.0.6",
"react-native-svg": "^6.0.0"
...
}
The additional package.json
entry would need to be documented in future Expo update guides, as with the current set of related dependencies.
I’m trying to find another way around this in my project right now, but feel I have exhausted the most reasonable options (manually editing package-lock.json is a no-go). If anyone can provide a suggestion, it would be much appreciated.