React-apollo: Fail to compile project. Error 'FetchMoreQueryOptions<TVariables, K>' requires 2 type argument(s).

[euvs]

My TypeScript project fails to compile with the following error:

../../node_modules/react-apollo/types.d.ts(31,35): error TS2314: Generic type 'FetchMoreQueryOptions<TVariables, K>' requires 2 type argument(s).
../../node_modules/react-apollo/types.d.ts(36,62): error TS2314: Generic type 'UpdateQueryOptions<TVariables>' requires 1 type argument(s).

I did a bit of poking around, it seems the problem is around this line.

https://github.com/apollographql/react-apollo/blob/5167cdd5d0ae278dd439436363b63ae919b4c998/src/types.ts#L52

FetchMoreQueryOptions and UpdateQueryOptions are generics imported from apollo-client.

I could workaround the problem by setting "skipLibCheck": true option in my tsconfig.json file.
If I set this flag, the error goes away.

I noticed that react-apollo's tsconfig.json file also has this option set.

[cobraz]

I'm having the same issue.

[MathieuDelafosse]

Same here. Strongly annoying when trying to publish an npm package.

[ptiwana1]

I am having the same issue, is this an issue in the recent update?

[ssamuelm]

Same issue here. Nothing works even if I revert back to the old package versions. Anyone found the solution yet? Help is much appreciated.

Thanks!

[MathieuDelafosse]

The skipLibCheck: true in tsconfig.json workaround submitted by @euvs solved my issue to, even if it is maybe not the best long-term approch.

[cbyte]

Same issue here for Angular Apollo- the workaround does not work for me

[ssamuelm]

I am using React Apollo and the workaround doesn't work for me too

[JohannesHoppe]

@cbyte This works for Angular Apollo, too! Change your topmost tsconfig.json

[maddy027]

Why I am getting this error. Someone pls help me on this. Looks like thread is still open

[aneilbaboo]

I was able to fix this issue by upgrading to the latest versions of @types/react (16.4.11) and react-apollo (2.1.11). Along the way, I ended up upgrading some other packages, which may also be necessary. Here's a selection of relevant dependencies from my package.json, with (*) beside all the packages which I upgraded.

*    "apollo-boost": "0.1.7",
*    "apollo-cache": "1.1.9",
    "apollo-cache-inmemory": "^1.2.8",
    "apollo-client": "^2.4.0",
    "apollo-client-preset": "^1.0.8",
    "apollo-link-context": "^1.0.8",
    "apollo-link-http": "^1.5.4",
*    "apollo-utilities": "1.0.13",
*    "graphql-anywhere": "4.1.11",
*    "react": "^16.4.2",
*    "react-apollo": "^2.1.11",
    "react-dev-utils": "4.0.1",
    "react-dom": "16.1.1",
    "react-fastclick": "3.0.2",
    "react-fontawesome": "1.6.1",
    "react-iscroll": "2.0.3",
    "react-loadable": "5.3.1",
    "react-redux": "5.0.6",
    "react-router-dom": "4.2.2",
    "react-router-redux": "5.0.0-alpha.8",
    "react-scroll-parallax": "1.2.1",
    "react-select": "1.0.0-rc.10",
    "react-toastify": "3.2.2",
    "react-transition-group": "2.2.1",
    "reactstrap": "^6.4.0",
    "redux": "3.7.2",
    "redux-logger": "3.0.6",
    "redux-saga": "0.16.0",
*    "@types/react": "^16.4.11",

[rosskevin]

Closing - housekeeping.

[yordis]

@rosskevin does housekeeping means fixed issue or just closed it?

[rosskevin]

@yordis this is an error in userland. There is nothing to fix.

[cobraz]

@rosskevin I don't remember this issue. I must have fixed it somehow. However in my opinion, closing and saying it’s a userland issue is not a good way to go about. We are leaving future developers and those who commented above without a clue.

A problem, even without something to code is still a problem that needs a fix.

[rosskevin]

This is a common typescript problem and not a react-apollo issue. Types get out of sync and the workspace needs a rebuild.

npm ci or rm -rf node_modules && yarn. Worst case ncu -a first (npm-check-updates).

[yordis]

Everything is userland since that is where you use the dependency.

Interesting that many users have the same situation.

Interesting enough I am just watching it instead of commenting so I can remove what others recommend: "skipLibCheck": true when the package fixes the issue.

Since the recommended fix is not an actual fix to the issue, but just a workaround, and also have downsides in the TypeScript project since you are going blindly on 3rd party libraries.

This is a common typescript problem and not a react-apollo issue.

That is not entirely true, react-apollo is written on TypeScript and the declaration types are maintained on this package. If, the declaration files were in @types/react-apollo then you will be 100% right, but again, it is not the case.

I understand that you want to keep the image of the packages high by closing issues, but I can't support those practices as an OSS contributor myself.

[rosskevin]

I recommend strongly against skipLibCheck: true. If you do so, do it temporarily and add an issue to your own issue tracker to revert it later.

I understand that you want to keep the image of the packages high by closing issues, but I can't support those practices as an OSS contributor myself.

Is this still an issue? CI is green and these are static types. Ah, if someone enabled skipLibCheck here, that's not a good thing.

We had some issues with third-party graphql package types that were broken which were updated in July. I'll PR the skipLibCheck reversion and see what happens. It should be checked here if at all possible.

[rosskevin]

No more skipLibCheck but note that had to add lib esnext.asynciterable which may have been the reason it was added to begin with - which I think is a mistake. Regardless, I have more confidence now with compatibility. https://github.com/apollographql/react-apollo/pull/2695/files