Closed himiranov closed 2 years ago
@erikdjan Can you dig a little deeper in your environment, to figure out which function is failing (because it's not a function)? I don't see anything used by both mergeDeep.js
and transform.js
that raises any flags. If you're running this code in an unusually old JS environment, there could be missing polyfills, but nothing jumps out at me.
@benjamn
Several hours of debbuging and I have found next info:
return __assign(__assign({}, node), { selections: __spreadArrays(selections, [TYPENAME_FIELD]) });
this line in transform.js:133
throws an error, because __spreadArrays
is undefined
.
Here is our package.json
dependencies:
{
"dependencies": {
"@apollo/client": "3.1.3",
"@loadable/component": "5.12.0",
"@loadable/server": "5.12.0",
"ajv": "5.2.3",
"apollo-fetch": "0.7.0",
"classnames": "2.2.6",
"cookie": "0.3.1",
"cookies-js": "1.2.3",
"core-js": "^3.6.4",
"dayjs": "1.8.20",
"deepcopy": "^2.0.0",
"gettext-parser": "2.1.0",
"graphql": "15.3.0",
"isbot": "2.5.3",
"js-yaml": "3.13.1",
"node-fetch": "1.7.3",
"nprogress": "0.2.0",
"prom-client": "11.2.1",
"prop-types": "15.7.2",
"react": "16.13.1",
"react-dom": "16.13.0",
"react-easy-swipe": "0.0.18",
"react-helmet": "5.2.1",
"react-lazyload": "2.5.0",
"react-router-dom": "5.1.2",
"react-transition-group": "4.4.1",
"regenerator-runtime": "0.13.3",
"ttag": "1.7.17",
"ua-parser-js": "0.7.19",
"url-polyfill": "1.1.7",
"whatwg-fetch": "2.0.4"
},
"devDependencies": {
"@babel/cli": "7.8.4",
"@babel/core": "7.8.4",
"@babel/plugin-proposal-class-properties": "7.8.3",
"@babel/plugin-proposal-json-strings": "7.8.3",
"@babel/plugin-proposal-object-rest-spread": "7.8.3",
"@babel/plugin-syntax-dynamic-import": "7.8.3",
"@babel/plugin-transform-modules-commonjs": "7.8.3",
"@babel/plugin-transform-react-constant-elements": "7.8.3",
"@babel/plugin-transform-react-inline-elements": "7.8.3",
"@babel/plugin-transform-runtime": "7.8.3",
"@babel/preset-env": "7.8.4",
"@babel/preset-react": "7.8.3",
"@loadable/babel-plugin": "5.12.0",
"@loadable/webpack-plugin": "5.12.0",
"autoprefixer": "9.7.4",
"babel-eslint": "10.1.0",
"babel-loader": "8.0.6",
"babel-plugin-ttag": "1.7.24",
"css-loader": "1.0.1",
"css-mqpacker": "7.0.0",
"eslint": "6.8.0",
"eslint-loader": "4.0.2",
"eslint-plugin-babel": "5.3.0",
"eslint-plugin-deprecate": "0.7.0",
"eslint-plugin-import": "2.20.1",
"eslint-plugin-jsx-a11y": "3.0.2",
"eslint-plugin-react": "6.10.3",
"eslint-plugin-react-hooks": "1.7.0",
"eslint-plugin-xss": "0.1.9",
"file-loader": "4.2.0",
"jsx-loader": "0.13.2",
"mini-css-extract-plugin": "0.9.0",
"name-all-modules-plugin": "1.0.1",
"nodemon": "1.19.4",
"optimize-css-assets-webpack-plugin": "5.0.3",
"optimize-js-plugin": "0.0.4",
"postcss": "7.0.26",
"postcss-automath": "1.0.1",
"postcss-clean": "1.1.0",
"postcss-color-function": "4.0.1",
"postcss-conditionals": "2.1.0",
"postcss-each": "0.10.0",
"postcss-easy-import": "3.0.0",
"postcss-extend": "1.0.5",
"postcss-for": "2.1.1",
"postcss-loader": "3.0.0",
"postcss-mixins": "6.2.3",
"postcss-nested": "3.0.0",
"postcss-reporter": "5.0.0",
"postcss-variables": "1.1.1",
"sort-css-media-queries": "1.4.3",
"style-loader": "0.23.1",
"stylelint": "9.10.1",
"sugarss": "1.0.1",
"svg-sprite-loader": "4.1.6",
"svgo": "1.3.2",
"svgo-loader": "2.2.1",
"ttag-cli": "1.7.22",
"webpack": "4.44.1",
"webpack-bundle-analyzer": "3.7.0",
"webpack-cli": "3.3.11",
"webpack-dev-server": "3.10.3",
"webpack-manifest-plugin": "2.2.0"
},
}
Do we miss smth in our package.json
dependencies?
That helper function comes from tslib
, which is a dependency of @apollo/client
and many other TypeScript projects. What version do you see in node_modules/tslib/package.json
?
tslib@1.9.3
Ah ha! The @apollo/client
package requires at least tslib@1.10.0
. Version 1.9.3 does not export the __spreadArrays
helper, but versions ≥1.10.0 do export it. To fix this, run
npm install tslib@1.x
in your application to get the latest 1.x version (currently 1.13.0).
As a side note, although I don't know anything about your experience, tracking down problems like this does not have to take hours. If you keep investing in your debugging skills, I promise this kind of task will become easy for you. Part of the game is asking the right sequence of questions—What's failing? Why isn't that function defined? Where should it be coming from? Why isn't it exported? Do I have the right version of that package?—and another part is getting good with a graphical debugger like the Chrome Devtools. Also, you can modify the contents of your node_modules
packages to add your own console.log
or debugger
statements. Just be sure to run npm ci
later to reinstall everything from scratch. Good luck!
Thank you so much, installing tslib@1.13.0
fixed the problem.
And I agree with you that tracing such problems does not have to take hours, but I don't have a lot of experience of debugging libraries code. And it was a little big harder because of webpack
:)
But it was nice experience and it would help me in my future work.
Also, we don't use TypeScript in our project, so we don't even have tslib
dependency, but it's version is required to be higher that 1.10.0
for @apollo/client
?
Also, we don't use TypeScript in our project, so we don't even have
tslib
dependency, but it's version is required to be higher that1.10.0
for@apollo/client
?
Yep, and it should be installed automatically along with @apollo/client
(so you don't have to install it yourself), but sometimes a package-lock.json
file can hold back the versions of some dependencies (at least that's my guess here).
Interesting Thank you so much for your assistance ;)
Also, we don't use TypeScript in our project, so we don't even have
tslib
dependency, but it's version is required to be higher that1.10.0
for@apollo/client
?Yep, and it should be installed automatically along with
@apollo/client
(so you don't have to install it yourself), but sometimes apackage-lock.json
file can hold back the versions of some dependencies (at least that's my guess here).
When merging I had to redo my package-lock file otherwise I run into similar problems. I was a bit painful as I had to update other packages and make everything work together again.
Yep, I got into the same situation, but it didn't take a lot of time.
Hello Im getting this error also
import { graphql, gql, useQuery, Mutation, Query } from '@apollo/client';
26 const LoginMut = gql`
1 mutation Login($username: String!, $password: String!) {
2 login(username: $username, password: $password) {
3 user {
4 username
5 }
6 csrf
7 validation {
8 status
9 errors
10 }
11 }
12 }
13 `;
TypeError: Object(...) is not a function
./src/screens/Auth/login.js
src/screens/Auth/login.js:214
211 | },
212 | });
213 |
> 214 | const Login = withStyles(styles)(graphql(LoginMut)(LoginStub));
215 |
216 | Login.propTypes = {
217 | classes: PropTypes.object.isRequired,
is it that graphql(Mutation)(Component)
no longer supported?
I tried const Login = withStyles(styles)(graphql(LoginMut)(()=>null));
with the same error ... So I think its graphql that is causing the error.
This is how I have my cache set up
const cache = new InMemoryCache({
possibleTypes
}).restore(window.__APOLLO_STATE__);
and i have installed npm install tslib@1.x
I have 62 components that I would have to re-write to make this work if graphql(Query)(components) no longer works and I have not read about this change in the https://github.com/apollographql/apollo-client/blob/master/CHANGELOG.md.
I had to install ts-invariant
. I'm using @apollo/client 3.3.11
we've had this issue trying to upgrade from 3.2.x
to 3.3.x
. i've confirmed (by locking Yarn package resolution to an explicit version) that the issue starts on 3.3.0
as @beedaan suggested, manually installing the ts-invariant
package seems to fix the issue... but it's not at all clear why this would be the case
It seems 3.3.x Apollo requires libraries which in turn require tslib v2
Also latest graphql-tag (2.12.5) requires tslib v2
This gives the same error as above
I've had to install 3.0.x and pin graphql-tag
I am using "@apollo/client": "^3.4.8", and
Also, we don't use TypeScript in our project, so we don't even have
tslib
dependency, but it's version is required to be higher that1.10.0
for@apollo/client
?Yep, and it should be installed automatically along with
@apollo/client
(so you don't have to install it yourself), but sometimes apackage-lock.json
file can hold back the versions of some dependencies (at least that's my guess here).Ah ha! The
@apollo/client
package requires at leasttslib@1.10.0
. Version 1.9.3 does not export the__spreadArrays
helper, but versions ≥1.10.0 do export it. To fix this, runnpm install tslib@1.x
in your application to get the latest 1.x version (currently 1.13.0).
As a side note, although I don't know anything about your experience, tracking down problems like this does not have to take hours. If you keep investing in your debugging skills, I promise this kind of task will become easy for you. Part of the game is asking the right sequence of questions—What's failing? Why isn't that function defined? Where should it be coming from? Why isn't it exported? Do I have the right version of that package?—and another part is getting good with a graphical debugger like the Chrome Devtools. Also, you can modify the contents of your
node_modules
packages to add your ownconsole.log
ordebugger
statements. Just be sure to runnpm ci
later to reinstall everything from scratch. Good luck!
I am using "@apollo/client": "^3.4.8",
and tslib version is 2.3.1
and I face the same error
TypeError: (0, _client.withApollo) is not a function. (In '(0, _client.withApollo)(LoadOlderButton)', '(0, _client.withApollo)' is undefined)
at node_modules\react-native\Libraries\LogBox\LogBox.js:148:8 in registerError
at node_modules\react-native\Libraries\LogBox\LogBox.js:59:8 in errorImpl
at node_modules\react-native\Libraries\LogBox\LogBox.js:33:4 in console.error
at node_modules\expo\build\environment\react-native-logs.fx.js:27:4 in error
at node_modules\react-native\Libraries\Core\ExceptionsManager.js:104:6 in reportException
at node_modules\react-native\Libraries\Core\ExceptionsManager.js:171:19 in handleException
at node_modules\react-native\Libraries\Core\setUpErrorHandling.js:24:6 in handleError
at node_modules\expo-error-recovery\build\ErrorRecovery.fx.js:12:21 in ErrorUtils.setGlobalHandler$argument_0
at node_modules\regenerator-runtime\runtime.js:63:36 in tryCatch
at node_modules\regenerator-runtime\runtime.js:294:29 in invoke
at node_modules\regenerator-runtime\runtime.js:63:36 in tryCatch
at node_modules\regenerator-runtime\runtime.js:155:27 in invoke
at node_modules\regenerator-runtime\runtime.js:165:18 in PromiseImpl.resolve.then$argument_0
at node_modules\react-native\node_modules\promise\setimmediate\core.js:37:13 in tryCallOne
at node_modules\react-native\node_modules\promise\setimmediate\core.js:123:24 in setImmediate$argument_0
at node_modules\react-native\Libraries\Core\Timers\JSTimers.js:130:14 in _callTimer
at node_modules\react-native\Libraries\Core\Timers\JSTimers.js:181:14 in _callImmediatesPass
at node_modules\react-native\Libraries\Core\Timers\JSTimers.js:441:30 in callImmediates
at node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:387:6 in __callImmediates
at node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:135:6 in guard$argument_0
at node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:364:10 in guard
at node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:134:4 in flushedQueue
at [native code]:null in flushedQueue
at [native code]:null in invokeCallbackAndReturnFlushedQueue
In my case, this issue was being caused by tslib being hoisted, and other dependencies relying on tslib@1.x.x
. Since we're using yarn workspaces, the simple fix was to add "**/tslib"
to the "nohoist" line in our package.json.
Testing with: "@apollo/client": "^3.4.12", "apollo": "2.31.2", "graphql": "^15.4.0",
and got the same error as @FatmaMahmoud698 😢
when I use this import { withApollo } from '@apollo/client/react/hoc'; my problem solved @MateusAndrade
Hey guys! Thanks a ton for opening this issue. It's looking like we can consider it solved with the tslib@1.10.0 package requirement (Thanks ben!), so I'll be closing it shortly. Let me know if we want to leave this open.
All the best, Emmanuel, Intern :)
Intended outcome:
I migrate a project from apollo-client v2 to v3. Once the configuration updated,
ApolloClient
withInMemoryCache
should not throw any error.Actual outcome:
Making requests with
ApolloClient
andInMemoryCache
throws errors. This is because ofaddTypename
set to true.How to reproduce the issue:
I'm using super default configuration of ApolloClient:
So any request that I do - throws this error. When I disable
addTypename
forInMemoryCache
I have same errorObject(...) is not a function
with second query while merging fields:NOTE: ApolloClient v2 with such configuration work nice, without any errors.
Versions
"@apollo/client": "3.0.0"
and higher. Also I tried changinggraphql
package versions from14.0.0
to the highest one - errors still present.