Definitelytyped: Aphrodite: incompatible with @types/react 15.6.0?

Not sure what's going on, but I'm getting similar issues with @types/react-redux and @types/react-dom. Bizarrely, npm install produces a working node_modules but yarn results in a node_modules that's broken:
https://gist.github.com/ajaska/e3ae7420946ece1e91e73cf614f6d2a3

I took a look at this; yarn creates those sub-node_modules directories (so getting different versions? unsure) but npm install doesn't?

  "dependencies": {
    "@types/react": "^15.0.38",
    "@types/react-dom": "^15.5.1",
    "@types/react-redux": "^4.4.46",
    "react": "^0.14.9",
    "react-dom": "^0.14.9",
    "react-redux": "^5.0.5",
}

@ajaska Thanks! https://github.com/yarnpkg/yarn/issues/1334#issuecomment-319522102 may be relevant enough to be worth subscribing to. I am using Yarn as well; it wouldn't surprise me if this is yarn-specific.

I can reproduce this using the official TypeScript React Starter guide. This is a broken package.json:

{
  "name": "my-app2",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@types/jest": "^20.0.5",
    "@types/node": "^8.0.19",
    "@types/react": "^15.6.0",
    "@types/react-dom": "^15.5.1",
    "react": "^15.6.1",
    "react-dom": "^15.6.1",
    "react-scripts-ts": "2.5.0"
  },
  "devDependencies": {},
  "scripts": {
    "start": "react-scripts-ts start",
    "build": "react-scripts-ts build",
    "test": "react-scripts-ts test --env=jsdom",
    "eject": "react-scripts-ts eject"
  }
}

It broke when I changed "@types/react": "^16.0.0", to "@types/react": "^15.6.0",.

I'm seeing this elsewhere in the wild:

• https://stackoverflow.com/questions/45304086/ts2403-error-at-every-typescript-react-project
• https://stackoverflow.com/questions/45468683/error-at-node-modules-types-react-dom-subsequent-variable-declarations-mus

No idea who to ask for support here, @onigoetz ? @RyanCavanaugh ? Could you take a look or direct me towards someone more qualified? Thank you!

And again, yarn will produce a broken node_modules whereas npm install will produce one that functions just fine.

I experienced the same problem and did some digging. I'm not absolutely sure what the problem is or the fix, but here's what I think is happening:

Some @types package.json files have "@types/react": "*" as dependencies, which means yarn places @types/react 16.0.0 (as of now) into the sub-node_modules directories. yarn's TypeScript transpilation step is picking up one of these files instead of the top-level @types/react/index.d.ts file. npm doesn't create sub-node_module directories (since * means any, not latest), so there's no collision.

My temporary development-only solution is to delete these lower-level @types/*/node_modules directories.

Adding React to the paths object in my tsconfig.json file solved the issue for me for now:

{
    "compilerOptions": {
        "typeRoots": [
            "node_modules/@types"
        ],
        "paths": {
            "react": ["node_modules/@types/react"] <---Here
        }
}

@fabianishere I like that solution, but it adds a bit of a maintenance cost (i.e. this isn't specific to @types/react). Do you know what the default tslint behavior is? Do lower-level definitions overwrite higher-level of the same name? That seems backwards.

@goldins Did you mean tslint? I don't understand why you're asking about it. Maybe you meant tsc?

Yes, I must have meant tsc. Apologies, I'm just getting started with TypeScript.

@goldins The issue is that Yarn resolves packages that use the dependency @types/react: * to version 16.0.0, while I have @types/react 15.6.1 installed. This means that two versions will be installed which causes conflicts.

If you for example try to import react-dom, TypeScript will load its type definitions at node_modules/@types/react-dom. This package also loads React's type definitions and TypeScript will first look for these in the node_modules of that directory (thus node_modules/@types/react-dom/node_modules/@types/react). This directory is linked to version 16.0.0 of the React type definitions

If you then import react, TypeScript will load the type definitions at node_modules/@types/react, which is still at version 15.6.1.

By adding react to your paths, you tell the TypeScript compiler that it should always resolve to a certain path.

Had this same issue. yarn upgrade resulted in this error. npm install did not.

It turns out yarn was installing _dependent_ node_modules directories inside of @types packages. For instance, I received node_modules/@types/enzyme/node_modules and node_modules/@types/react-dom/node_modules directories. These directories of course themselves depended on type declarations that were also installed inside of the @types directory as top-level type declarations as expected. Deleting these two directories manually solved the issue. Looks like it's a bug in the yarn and definitelyTyped interaction...

As a side note Yarn is not the only offender here. If a package lists specific version of @types/react as a non-dev dependency (e.g. botframework-webchat does that) you'll get the same problem with NPM - it'll create node_modules/{package}/node_modules/@types/react which will then be picked up by tsc and fail the compilation due to React definitions incompatibility.
@goldins If I'm not mistaken TypeScript definitions never overwrite each other, they are always merged. Behavior we see is probably described here https://www.typescriptlang.org/docs/handbook/tsconfig-json.html :

By default all visible “@types” packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible; specifically, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

So @fabianishere 's use of "paths" seems like the only proper way to fix the problem. I'm not sure about typeRoots though - it should be the default value so no need to overwrite it, at least it works for me.
Also skipLibCheck: true will work yet it's really a shotgun approach and should be used only if you're OK with the consequences.

@delight-by I can't be specific, but yarn is a lot worse in this regard than npm. In my case, I dropped back from yarn to npm because of this behavior, and all these problems went away. I'm not disagreeing you about npm's behavior with pinned versions - just saying yarn appears to make these package-specific node_modules in many more cases.

@estaub Yarn definitely has a bug with * (any) version in package.json triggering the latest version install. That's exactly why I temporarily switched to NPM like you and most of the people here. But only until I faced the same problem with NPM couple of days later)

I've logged the yarn bug here https://github.com/yarnpkg/yarn/issues/4136

I remove @types/react in my package.json, and let yarn install the latest version of @types/react (16.0.5), seems fix the problem

I removed the package.json entry of @types/react-dom and re install using yarn add @types/react-dom and it seems to be ok now for me

@joevo2 solution work's for me, but is there any better way to do it?

@joevo2 use yarn add solve it, then use npm view @types/react-dom and reinstall right version to package.json

Just remove all react & type@react from dependency, then re-npm install them, fix my issue~

For yarn users: rm -rf node_modules yarn.lock && yarn worked around this for me. Note that you must remove the yarn.lock, otherwise it won't work around the issue.

@rosskevin was running in circles around this issue for the past few hours. Thanks for posting this solution, that was the one that actually helped!

in case it's helpful to anyone - for me this was due to mismatched versions in my react and react-ui definitions

Add

"resolutions": {
   "@types/react": "^16.0.40"
 }

to package.json

Reinstall node_modules with yarn install

Note it's a bit hacky to force package version for every package in node_modules, but in case of @types it's rather safe.