Breaking dependency conflict introduced with Expo SDK 26, and a possible fix

Expo SDK
1

When attempting to update to Expo SDK 26 with all documented steps, my project fails to run.

35585192-722d8a62-05de-11e8-9e18-8c820d480dcd
35585192-722d8a62-05de-11e8-9e18-8c820d480dcd750×1334 79.2 KB

(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.

2

Thanks for understanding and describing the problem so well. I think it is possible with yarn to force both dependencies to resolve to the same thing: https://github.com/yarnpkg/yarn/pull/4105

Will that unblock you?

3

Sadly not on this particular project, as the team is using a non-trivial Yarn, Lerna and npm repository setup. npm is used at our Expo project level, and doesn’t have this facility :confused:

1 Like
4

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.