@types/react
package and had problems.Definitions by:
in index.d.ts
) so they can respond.file: '.../@types/react/index.d.ts'
severity: 'Error'
message: 'Interface 'Element' cannot simultaneously extend types 'ReactElement<any>' and 'ReactElement<any>'.
Named property 'type' of types 'ReactElement<any>' and 'ReactElement<any>' are not identical.'
at: '3454,19'
source: 'ts'
file: '.../@types/react/index.d.ts'
severity: 'Error'
message: 'Interface 'ElementClass' cannot simultaneously extend types 'Component<any, {}>' and 'Component<any, {}>'.
Named property 'refs' of types 'Component<any, {}>' and 'Component<any, {}>' are not identical.'
at: '3455,19'
source: 'ts'
I have just hit this issue.
It turns out that @types/react-dom
had a nested version of @types/react
, that interfered with the version of @types/react-dom
installed in my project.
However, this only happens when I install packages with yarn. Deleting node_modules
and installing with npm fixed the issue for me.
@MortenHoustonLudvigsen is right. Deleting the nested react types from all react-related packages seems to have done the trick.
Didn't we have a better solution?
I have the same issue. Does that mean we cannot use yarn with react and TS without ugly hacks?
The yarn locking algorithm sometimes resolves your packages with duplicates.
It does so consistently when doing yarn upgrade
with a package that is also a sub-dependency of another package.
The package ends up duplicated with the upgraded version at the root of your node_module
, and with the former version duplicated as a subdependency in the node_module
of the packages that have it as a dependency. This is suboptimal in our use case but it is not a bug per-say.
Actions you _need to_ take:
@type
dependency that is also a sub-dependency. If they can resolve to the same version (most of the time), both packages will be de-duped, ending up at the root with the proper version. Upgrading both the parent package and the @type package might also work.Actions the community _may_ take:
yarn upgrade
algorithm to avoid the described situation, assuming this is an acceptable behaviour.I have the same issue, but I'm not using yarn. I wiped node_modules
and package-lock.json
and reinstalled everything and it didn't help.
@vagarenko
I found this tweet by @basarat 🌹.
It helped me figure out that the version of react-datetime I was using had @types/react as a hard dep which was causing the issue.
I updated react-datetime to the latest version which included this fix.
No more errors!
Removing node_modules/
and yarn.lock
solved the issue for me
I resolved this without removing yarn.lock
or node_modules
by adding a resolution for @types/react
:
```
"resolutions": {
"**/@types/react": "16.4.14",
}
````
To elaborate on inversions comment for how to work-around this issue, yarn's page on selective dependency resolution says:
... lets you define custom package versions inside your dependencies through the resolutions field in your package.json file. Normally, this would require manual edits in the yarn.lock file.
When I searched my yarn.lock
file I found these:
"@types/react-dom@^15.5.0":
version "15.5.8"
resolved "https://registry.yarnpkg.com/@types/react-dom/-/react-dom-15.5.8.tgz#e2fe3d95fc443c2dc2786eba99223f4e0eeeac22"
dependencies:
"@types/react" "^15"
"@types/react-virtualized@^9.7.4":
version "9.18.8"
resolved "https://registry.yarnpkg.com/@types/react-virtualized/-/react-virtualized-9.18.8.tgz#779ada1f530688d5ca0e64816c3f06ef4c875af6"
dependencies:
"@types/prop-types" "*"
"@types/react" "*"
Note how the latter allows versions of react outside of 15 ("@types/react" "*"
), which is exactly what I had. I applied @inversion 's fix to my package.json, based on the version @types/react-dom
(presumably) resolved to:
"resolutions": {
"**/@types/react": "15.6.20"
}
I then deleted my node_modules and re-installed to convince myself it all worked, and it does. I probably could have been more specific in the resolutions and said: react-virtualized/**/@types/react
. At any rate, now I just need to remember to delete that when I update my direct dependencies in the future, and re-apply only if necessary.
Just to confirm that resolutions in package.json does the trick.
Anything else failed for both yarn and npm.
Are we saying npm should be the tool now to use with TS and react?
I have the same problem and found that react and react-dom in my project is old 15 version. After I updated them to 16, this problem is gone
Most helpful comment
The yarn locking algorithm sometimes resolves your packages with duplicates.
It does so consistently when doing
yarn upgrade
with a package that is also a sub-dependency of another package.The package ends up duplicated with the upgraded version at the root of your
node_module
, and with the former version duplicated as a subdependency in thenode_module
of the packages that have it as a dependency. This is suboptimal in our use case but it is not a bug per-say.Actions you _need to_ take:
@type
dependency that is also a sub-dependency. If they can resolve to the same version (most of the time), both packages will be de-duped, ending up at the root with the proper version. Upgrading both the parent package and the @type package might also work.Actions the community _may_ take:
yarn upgrade
algorithm to avoid the described situation, assuming this is an acceptable behaviour.