React Element and ElementClass Declaration Issue

[ddwwcruz]

• I tried using the @types/react package and had problems.
• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @johnnyreilly @bbenezech @pzavolinsky @digiguru @ericanderson @morcerf @tkrotoff @DovydasNavickas @onigoetz @richseviora

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'

[MortenHoustonLudvigsen]

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.

[ddwwcruz]

@MortenHoustonLudvigsen is right. Deleting the nested react types from all react-related packages seems to have done the trick.

[asfernandes]

Didn't we have a better solution?

[AllainPL]

I have the same issue. Does that mean we cannot use yarn with react and TS without ugly hacks?

[bbenezech]

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:

• You have to wipe your .lock file when updating a @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.
• You could remove your own dependency, since it is already required.

Actions the community may take:

• Yarn could change the yarn upgrade algorithm to avoid the described situation, assuming this is an acceptable behaviour.
• DefinitelyTyped probably should avoid dependencies and rely instead on peer dependencies, since it does not support duplicated libs at its core.
• TypeScript could make duplicated dependencies work by using only the latest (?) version of duplicated packages.

[vagarenko]

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.

[ghost]

@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!

[wcandillon]

Removing node_modules/ and yarn.lock solved the issue for me

[inversion]

I resolved this without removing yarn.lock or node_modules by adding a resolution for @types/react:

	"resolutions": {
		"**/@types/react": "16.4.14",
         }

[cloverich]

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.

[ThomasLabstep]

Just to confirm that resolutions in package.json does the trick.

Anything else failed for both yarn and npm.

[quantuminformation]

Are we saying npm should be the tool now to use with TS and react?

[ublue1024]

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

[andreyfrolovwork]

Adding in package.json

"resolutions": {
     "@types/react": "17.0.30",
     "@types/react-dom": "^18.0.5",
     "@types/react-redux": "^7.1.24",
     "@types/react-router-dom": "^5.3.3"
   }

helped me solve this problem