Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aphrodite: incompatible with @types/react 15.6.0? #18484

Open
estaub opened this Issue Jul 28, 2017 · 24 comments

Comments

Projects
None yet
@estaub
Copy link
Contributor

estaub commented Jul 28, 2017

@types/aphrodite 0.5.6 appears to be incompatible with @types/react 15.6.0 and a few versions before that. For all HTML element types, I see a message of the form:

Error:(2989, 13) TS2403:Subsequent variable declarations must have the same type. Variable 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>', but here has type 'HTMLProps<HTMLAnchorElement>'.

complaining about <my project>/node_modules/@types/aphrodite/node_modules/@types/react/index.d.ts

The element definitions have changed, e.g.

Aphrodite's embedded react/index.d.ts:
a: React.HTMLProps<HTMLAnchorElement>;
15.6.0
a: React.DetailedHTMLProps<React.AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>;

When fixing this, consider changing the @types/aphrodite/package.json dependency:

"dependencies": {
        "@types/react": "*"
    },

to require 15.6 or better.

@types/aphrodite 0.5.6 is compatible with @types/react 15.0.35, which I've fallen back to.

I'm a noob at dealing with these kinds of version-dependency issues on libs, especially on @types. Otherwise, I'd PR it. I have no idea how the @types/aphrodite/package.json is generated, or how @types/aphrodite/node_modules is filled, or where the @types/react version '15.0.83' is specified.

@tkrotoff fyi

@ajaska

This comment has been minimized.

Copy link

ajaska commented Aug 1, 2017

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",
}
@estaub

This comment has been minimized.

Copy link
Contributor Author

estaub commented Aug 1, 2017

@ajaska Thanks! yarnpkg/yarn#1334 (comment) 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.

@ajaska

This comment has been minimized.

Copy link

ajaska commented Aug 2, 2017

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:

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

@ajaska

This comment has been minimized.

Copy link

ajaska commented Aug 2, 2017

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

@goldins

This comment has been minimized.

Copy link

goldins commented Aug 2, 2017

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.

@fabianishere

This comment has been minimized.

Copy link

fabianishere commented Aug 3, 2017

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
        }
}
@goldins

This comment has been minimized.

Copy link

goldins commented Aug 3, 2017

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

@estaub

This comment has been minimized.

Copy link
Contributor Author

estaub commented Aug 3, 2017

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

@goldins

This comment has been minimized.

Copy link

goldins commented Aug 3, 2017

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

@fabianishere

This comment has been minimized.

Copy link

fabianishere commented Aug 3, 2017

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

@jbmilgrom

This comment has been minimized.

Copy link

jbmilgrom commented Aug 3, 2017

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

@delight-by

This comment has been minimized.

Copy link

delight-by commented Aug 13, 2017

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.

@estaub

This comment has been minimized.

Copy link
Contributor Author

estaub commented Aug 13, 2017

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

@delight-by

This comment has been minimized.

Copy link

delight-by commented Aug 13, 2017

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

@glentakahashi

This comment has been minimized.

Copy link

glentakahashi commented Aug 14, 2017

I've logged the yarn bug here yarnpkg/yarn#4136

@davidctj

This comment has been minimized.

Copy link

davidctj commented Sep 21, 2017

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

@joevo2

This comment has been minimized.

Copy link

joevo2 commented Sep 25, 2017

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

@myangsc

This comment has been minimized.

Copy link

myangsc commented Oct 5, 2017

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

@myangsc

This comment has been minimized.

Copy link

myangsc commented Oct 5, 2017

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

@markwangen

This comment has been minimized.

Copy link

markwangen commented Nov 14, 2017

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

@rosskevin

This comment has been minimized.

Copy link
Contributor

rosskevin commented Dec 8, 2017

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.

@zubivan

This comment has been minimized.

Copy link
Contributor

zubivan commented Dec 9, 2017

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

@dleavitt

This comment has been minimized.

Copy link

dleavitt commented Mar 7, 2018

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

@pie6k

This comment has been minimized.

Copy link

pie6k commented Mar 7, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.