Multiple versions of @types/react causes TypeScript errors when using react-native-svg on a bare workflow

[ngregory-rbi]

Summary

After running expo init (using the blank TypeScript template and then expo eject on a brand new environment, of the many packages installed, there are:

• @types/react@17.0.45¹
• @types/react-native@0.66.18²
  • @types/react@18.0.12³

Then running expo install react-native-svg, react-native-svg@12.3.0 is installed.

Attempting to use any component from that package though leads to a TS2786 error (... is not a valid JSX element). When I researched this in reference to react-native-svg the issue of multiple versions of @types/react came up as the cause, and that does appear to be what is happening here.

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

bare

What platform(s) does this occur on?

Android, iOS, Web

SDK Version (managed workflow only)

No response

Environment

expo-env-info 1.0.3 environment info:
System:
OS: macOS 12.4
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 14.17.3 - ~/.nvm/versions/node/v14.17.3/bin/node
Yarn: 1.22.18 - ~/.nvm/versions/node/v14.17.3/bin/yarn
npm: 8.7.0 - ~/.nvm/versions/node/v14.17.3/bin/npm
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
IDEs:
Android Studio: 2021.2 AI-212.5712.43.2112.8512546
Xcode: 13.4/13F17a - /usr/bin/xcodebuild
npmPackages:
expo: ~45.0.0 => 45.0.5
react: 17.0.2 => 17.0.2
react-dom: 17.0.2 => 17.0.2
react-native: 0.68.2 => 0.68.2
react-native-web: 0.17.7 => 0.17.7
Expo Workflow: bare

Reproducible demo

https://github.com/ngregory-rbi/my-app

Footnotes

1. installed, or at least enforced by https://exp.host/--/api/v2/versions/latest which currently defines "@types/react": "~17.0.21" as a requirement for Expo 43, 44, and 45. (https://semver.npmjs.com/ confirms that will result in the version 17.0.45) ↩

2. installed by "@types/react-native": "~0.66.13" in the package.json for the app. ↩

3. installed by "@types/react": "*" in the package.json for @types/react-native@0.66.18. ↩

[ngregory-rbi]

Adding in the old version as under resolutions "fixes" the issue (ngregory-rbi/my-app@0579), but this is definitely a hack-y way of fixing it. Why doesn't Expo support @types/react@18.x.x?

EDIT: This also does not fix the issue in my actual project, which is vastly more complicated.
EDIT 2: Using patch-package to patch the react-native-svg type definitions to import from the "correct" @types/react package works too, but it's still hack-y.

[Simek]

Hello @ngregory-rbi, unfortunately supporting React 18 it's a bit more complicated than upgrading the package version in dependencies, and even latest version of stable React Native release do not truly support React 18.

Not sure how your project is setup and why the newer version of types is fetch in there, but for now you should use React 17 in RN and Expo projects and forcing resolution of correct types seems like a valid solution

Refs: https://twitter.com/Kelset/status/1534881745774039045/photo/1

You can read a little bit more about the relation between React Native and React 18 in the official docs:

• https://reactnative.dev/docs/next/react-18-and-react-native

Also, you probably should not use expo eject anymore, this also might be the root cause for the issue.

[ngregory-rbi]

Not sure how your project is setup and why the newer version of types is fetch in there

I explained clearly in my original post about why the newer version of the types are being pulled in. It's because @types/react-native pulls them in. Seeing its package.json it appears it's because it has an * version for @types/react, so it pulls in the latest ones.

but for now you should use React 17 in RN and Expo projects and forcing resolution of correct types seems like a valid solution

Unfortunately, my actual project is much more complicated, and setting the resolution broke other dependencies.

Additionally, for some reason, my current project type-checks any elements I use by the types in @types/react-native -> @types/react instead of the hoisted dependency. I was unable to figure out a way to point the TypeScript compiler to look at the hoisted dependency, so I forced the react-native-svg type definition file to point to the aforementioned types just so both it and the compiler were on the same page. So now they're both pointing to v18, so they're both wrong, but at least they both agree.

If there was some way to tell the TypeScript compiler which version of @types/react to check against that would be better, but I don't think there is a way.

Also, you probably should not use expo eject anymore, this also might be the root cause for the issue.

expo prebuild does the same thing. It's not the root issue from what I can see. See above.

[Simek]

It's because @types/react-native pulls them in. Seeing its package.json it appears it's because it has an * version for @types/react, so it pulls in the latest ones.

You can use the resolution overwrite field for both type packages @types/react and @types/react-native.

Unfortunately, my actual project is much more complicated, and setting the resolution broke other dependencies.

This is probably due to usage of dependencies with mixed compatibility, which part of uses React 17 and some React 18. If you are not able to move the whole app to React 18, you should stay on the older version of packages, until you are able to do the full upgrade. Downgrade of the problematic packages should also resolve this problem.

[ngregory-rbi]

This is probably due to usage of dependencies with mixed compatibility, which part of uses React 17 and some React 18. If you are not able to move the whole app to React 18, you should stay on the older version of packages, until you are able to do the full upgrade. Downgrade of the problematic packages should also resolve this problem.

Unfortunately, due to business requirements, this is not possible. As mentioned though, it appears part of my issue is with the TypeScript complier checking my use of components against the wrong version of @types/react. Regardless though, as mentioned, I found a "solution" through patch-package.

I just more wanted to inform y'all about how your current workflow for bare apps does not support react-native-svg without some modifications (such as "resolutions").

[Simek]

I just more wanted to inform y'all about how your current workflow for bare apps does not support react-native-svg without some modifications (such as "resolutions").

I wasn't able to reproduce the problem with clean bare app generated from template and react-native-svg installed via expo command, so I still think that the problem is not general, but rather project specific.

Regardless though, as mentioned, I found a "solution" through patch-package.

That's nice to hear! So, can we close this issue, or is there something else you would like to add?

[ngregory-rbi]

I wasn't able to reproduce the problem with clean bare app generated from template and react-native-svg installed via expo command, so I still think that the problem is not general, but rather project specific.

Fascinating. I'm not sure what you did differently because I thought I did the same, given that all I did was run expo init and then expo prebuild/expo eject.

That's nice to hear! So, can we close this issue, or is there something else you would like to add?

If you were unable to reproduce, then perhaps. I would still be curious as to what we did differently, though.

[Simek]

There is also a know problem when working with certain versions of the types packages, and it has nothing to do with the Expo, React Native or any other third-party libraries. The problem has been reported a while ago in DT repository, and it has lead to the many false report in various places, see:

• Type errors because of types/react~17. #17101

If you were unable to reproduce, then perhaps. I would still be curious as to what we did differently, though.

I have checked out your app too, build it and run it on real hardware without any changes and I still cannot reproduce the problem, no warnings or errors are present.

So maybe there is something wrong with you Editor/IDE setup, from the previous cases I know that VSCode have some issue with React types too.

Saying that, I'm going to close the issue due to lack of correct repro since the discussion in there become a little bit unproductive. If you will be able to provide the repro which will always result in errors or warnings, no matter of the machine feel free to create a new issue.

[expo-bot]

Hi there! It looks like your issue requires a minimal reproducible example, but it is invalid or absent. Please prepare such an example and share it in a new issue.

The best way to get attention to your issue is to provide a clean and easy way for a developer to reproduce the issue on their own machine. Please do not provide your entire project, or a project with more code than is necessary to reproduce the issue.

A side benefit of going through the process of narrowing down the minimal amount of code needed to reproduce the issue is that you may get lucky and discover that the bug is due to a mistake in your application code that you can quickly fix on your own.

Resources

• "How to create a Minimal, Reproducible Example"
• "How to narrow down the source of an error"

Common concerns

"I've only been able to reproduce it in private, proprietary code"

You may not have spent enough time narrowing down the root cause of the issue. Try out the techniques discussed in this manual debugging guide to learn how to isolate the problem from the rest of your codebase.

"I didn't have time to create one"

That's understandable, it can take some time to prepare. We ask that you hold off on filing an issue until you are able to fully complete the required fields in the issue template.

"You can reproduce it by yourself by creating a project and following these steps"

This is useful knowledge, but it's still valuable to have the resulting project that is produced from running the steps, where you have verified you can reproduce the issue.