'Drawer.Navigator' cannot be used as a JSX component with TypeScript #10507
Comments
|
Hey! Thanks for opening the issue. The issue doesn't seem to contain a link to a repro (a snack.expo.dev link, a www.typescriptlang.org/play link or link to a GitHub repo under your username). Can you provide a minimal repro which demonstrates the issue? A repro will help us debug the issue faster. Please try to keep the repro as small as possible and make sure that we can run it without additional setup. |
|
Couldn't find version numbers for the following packages in the issue:
Can you update the issue to include version numbers for those packages? The version numbers must match the format 1.2.3. |
|
I haven't installed following packages since these packages are nothing to do with this case. I hope you understand this condition. BR, |
If it's that simple to reproduce then you can take a few seconds to copy/paste it on snack and repro the issue. Regardless even if it looks simple to you, doesn't mean it'll actually be simple to reproduce. Anyway, you haven't provided an error message either but from what I have seen, I can guess that this issue caused due to multiple versions of
All of this is highly specific to your project structure and not-straightforward to repro. If you still have issues after following the above steps, please open a new issue with a repro and full error-message. |
|
Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro. |
|
Hi satya164, Thank you for our swift reply. In short the issue was resolved. As soon as I remove the one with version 17, the issue was resolved. Thank you so much again. BR, |
|
By adding The reason why there are both @type/react 17 and 18 versions is "react-native" is pulling the latest "@types/react" which is 18 in this case. you can find it by checking yarn.lock file "@types/react@": |
|
Hi, Captain-Ray, Thank you for your advice. Yes, as you point out the root cause of the issue is the major bump of @types/react. I have resolved the issue by adding resolutions field in package.json. Since then, it works fine. Not only React Navigation, many packages are influenced with changes in @types/react as mentioned in as follows: BR, |
|
I can't get this to work. I've got "devDependencies": { "@types/react": "~17.0.21" }and have tried "resolutions": { "@types/react": "~18.0.5" }but no matter what I do (clear caches, run It looks like you're trying to use TypeScript but don't have the required dependencies installed. Would you like to install @types/react? … no
Please install @types/react by running:
yarn add --dev @types/react@~17.0.21
If you're not using TypeScript, please remove the TypeScript files from your project and delete the tsconfig.json.which then results in the TypeScript/JSX error again. It appears one can't have it both ways: one has to chose between either
Is there any way around this dilemma? |
|
@orome you need to use, as per your dev dependence |
|
Before using resolutions, I would recommend to confirm the version number of your @types/react by typing and you will get as follows: In my case, for example, you can see that the versions of @types/react are 17.0.44 and 18.0.3. Then you put following lines into package.json. Version 18 is not recommended because React Native is constructed on react v17. I hope you successfully resolve this case. The root cause of this problem is incompatibility between @types/react v17 and @types/react v18. Not only with react native, many people encounter the similar issue with several packages which use @types/react. BR, |
Thanks a lot. This fixed the issue. As I was using React version 17.0, and tried installing @types/react v18.0, is the reason my solution was not working. Now installed both Thanks again! |
|
The only thing that worked for me was downgrading react and react-dom to v17.0.1
|
|
@challengy1 I guess I'm really confused about two things then:
And another issue, I guess:
|
|
Hi, Orome I will try to answer your questions as follows: (1) What is 'resolutions' doing? (2) How do I discover this? I would recommend you to take a look at it. Not only with React-native, when you see an error message 'XXX cannot be used as a JSX component.' You need to investigate if there are multiple @types/react. (3) How on earth do I automage this? BR, Challengy |
|
@challengy1 I still don't get what |
|
Hi, Orome I will give you some more detail information as follows. Firstly, I will focus on procedure through which you can (anyway) establish your development environment. Please take following procedure step by step. (1) Cd to somewhere in which you plan to make your project. (2) expo init <name_of_the_project> for example as follows: (3) Cd to the project directory. (4) Check @types/react dependency by typing as follows: You will fine TWO @types/react in the result. I will discuss this later. (5) Add resolutions field into package.json as follows: I added only resolutions fields (with 3 lines as you see above.) (6) You will install some navigation related packages as follows (for example drawer): (7) When you use reanimated, you need to add a 'plugins' line into babel.config.js as follows: (8) With a test code as follows, you will confirm that the issue is resolved. (9) Kick start by typing as follows: Now, I will explain a bit about version conflict. @types/react@17.0.44 was installed because the project was built with typescript template. The important thing is that @types/react-native "by mistake" installs @types/react@18.0.6. The root cause of this problem is that react-native does NOT specify the version number. resolutions in the package.json 'specifies' the version to be used in this project. After adding resolution field, you will confirm as follows: Now this project uses @types/react@17.0.44 only. I hope you can successfully establish your environment. BR, Challengy |
|
Just a piece of minor information. On Package.json, the version number of @types/react is v17.0.21. But when your see yarn.lock file, you will find that v17.0.44 is actually installed. It is not necessary to stick on the version number mentioned in package.json. BR, Challengy |
|
@challengy1 I still don't understand (sorry). I'd always thought that the whole purpose of But are you saying that in fact something else (what?) can install an arbitrary version of (FWIW, for me |
|
Hi, Orome Any JavaScript / TypeScript project consists of many packages and each package has a lot of packages inside. This means we have a huge number of dependency-chains inside. Each package has its own package.json which specify name of the package with version number. In the file, you will witness @types/react as follows: The root cause of this problem is this "*" in the dependencies. Again, one of the root causes is incompatibility between V17 and V18 @types/react and another cause is specifying "asterisk" for @types/react in the @types/react-native file. I would recommend you to read all messages in the GitHub issue as follows: In this, you will read a message from KutnerUri as follows: Inserting resolutions in your project level package.json is one of the ways and you may find some other alternatives. Using resolutions is not idealistic but it is a pragmatic and effective way. BR, Challengy1 |
|
@challengy1 So the short answer is "yes"?
If so it seems a bit of a mess: If that's so why not just have an "I really mean it" flag that applies to |
No, your dependencies are installed and those versions are used when you import them into your code. If a package has another version of a dependency its
Different versions of a package may have different APIs/behavior. Forcing another version than what a package was tested with (and says it depends on) is likely to break things. |
|
Thanks satya164, Dear Orome, BR, Challengy1 |
|
@satya164 I can understand that other packages might need other versions of something my package has as a dependency, but if that's the case, why is my code exposed to the existence of that package? Maybe I'm coming from the wrong place altogether here. I would assume that there is some kind of LTS system of mutually compatible packages so that none of this would be an issue. And why not always use |
Because some code relies on things in global scope - such as And for the cases where it's not possible to mix 2 separate versions, forcing a single version isn't guaranteed to fix the issue due to API differences - it can cause other issues. In this specific case it works fine.
LTS doesn't have anything to do with compatibility. It just means the maintainer provides long term support for the package. There's a system called semver where there's API compatibility and forcing a version between matching semver won't break code. The package manager already takes care of deduplicating where the semver specified is compatible between 2 different versions and installs a single version instead. In this specific case
Like I said, it might break things due to API differences. It also doesn't make sense to do something which might fix an issue in rare cases but cause issues for majority of cases. |
|
@satya164 OK that clears things up a bit. I think what's confusing me is the lack of (what I was calling) LTS. What I meant was something like Stackage: something that ensures a collection of mutually compatible versions that work together. The React Native ecosystem seems to lack this, so maintaining dependencies is a bit of a free-for-all. If that's the case, how does one ever know if versions will work together, or ensure that somehow an incompatible version isn't added (in global scope). |
|
Only update react to version 18.0.6 like: |
|
I've got: and that works for me. Should I be using |
|
@captain-ray captain-ray Thank you! |
|
I don't think it is a good idea to mix multiple versions of @types/react in your project. BR, |
Wait what? I thought all this was about exactly that happening, beyond my control. |
|
For those having a similar issue with |
|
This worked for me (when using Expo SDK45 beta): package.json : {
"name": "example",
...
"devDependencies": {
...
"@types/react": "~17.0.21",
...
},
"resolutions": { "@types/react": "~17.0.21"},
"dependenciesComments": {
"@types/react": "Resolution because of this issue: https://github.com/react-navigation/react-navigation/issues/10507"
}
} |
|
Still having the issue with expo Typescript with Tabs template. yarn why @types/reactresult: => Found "@types/react@17.0.45"
info Has been hoisted to "@types/react"
info Reasons this module exists
- Specified in "devDependencies"
- Hoisted from "@types#react-native#@types#react"
info Disk size without dependencies: "184KB"
info Disk size with unique dependencies: "1.37MB"
info Disk size with transitive dependencies: "1.37MB"
info Number of shared dependencies: 3
✨ Done in 0.22s.Then, "resolutions": {
"@types/react": "~17.0.45"
},then, yarn install |
|
Been struggling with the same issue
My current react-native app has the following package.json contents Other react app's package.json And it is a monorepo, but I've checked that all of the package.json files have @types/react: 17.0.45 |
It's not working, i am still got the problem on expo |
|
Also still having this problem It works if I remove the package @types/react package from devDependencies but then expo forces me to install it |
|
I had this problem at the expo and nothing resolved it, even with resolutions. Until I found the solution, using version 18.0.0 inside resolutions "resolutions": {
"@types/react": "18.0.0"
} |
react-navigation/react-navigation#10507 버전이슈니 뭐니 어쩌고 다 했는데, 그냥 import 다시 새로적어주면 되는 이슈였음 ; 밤에 뭐했냐 진짜 ;;ㄱ허ㅏㅣ붖기ㅏ버
|
delete node modules and yarn install again |
Current behavior
In the code as follows, I encountered a TypeScript Error message saying 'Drawer.Navigator' cannot be used as a JSX component.
I encountered this issue with Bottom-tabs as well. With Native-Stack, however, No Typescript error was reported.
Expected behavior
I expect this TypeScript error message is resolved.
Reproduction
I attached the source code in the Current behavior. Nothing more.
Platform
Packages
Environment
The version of the expo-cli was 5.3.1, the latest one.
I made this project with expo init <project_name> with TypeScript support. (Simple configuration).
I have added a plugin in babel.config.js as follows:
The text was updated successfully, but these errors were encountered: