Definitelytyped: React Element and ElementClass Declaration Issue

Created on 6 Oct 2017  ·  13Comments  ·  Source: DefinitelyTyped/DefinitelyTyped

  • [x] I tried using the @types/react package and had problems.
  • [x] I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
  • [x] I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
  • [x] [Mention](https://github.com/blog/821-mention-somebody-they-re-notified) 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'

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

All 13 comments

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:

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

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

Was this page helpful?
0 / 5 - 0 ratings