-
Hi all. Since v4.3.0, I am hitting an issue on the useQuery() hook because of a QueryClient context retrieval from a component in an intermediate library. I have a custom library, with react, @tanstack/react-query and @tanstack/query-core defined as devDependencies, which defines a React component like this (simplified) :
Where ReactQueryResultWrapper is a React component defined in the same library which renders either the success result of the query, the error, or the 'loading' state. I transpile it using Babel, so I end up with a file like this :
Then, in a 'final' app based on react create app, with the previous lib, react, @tanstack/react-query and @tanstack/query-core defined as dependencies, in my index.tsx, I have the following:
When running this app (locally, with 'yarn start'), since v4.3.0 (and all subsequent versions), I have the following error ' This used to work since v4.0.1, up to v4.2.3, and thus, I cannot upgrade the @tanstack/query library to any following versions. By looking at https://github.com/TanStack/query/releases?page=3, i suspect this is due to the switch to ESM support (#4092), but I am not an expert at all on javascript modules. I made sure that I do not have multiple versions of either react nor @tanstack/query installed in the node_modules in the final app. It is likely that moving the useQuery() hook call in the component in the final app would fix the issue, but as the components in the intermediate library do much more than above, this would lead to a lot of duplicate code in the parent components. It looks like a bug to me, but I wanted to get some feedbacks before opening a ticket. Has someone experienced the issue ? Thanks a lot for any feedbacks and help. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Further, this really depends on your setup. Is the lib published to npm and then consumed? Is it part of a monorepo? If so, which monorepo setup: yarn workspaces, pnpm, nx, something else? It also depends on the bundler you're using (next, CRA, something custom with webpack, vite ?)
so the very simple explanation that is almost always true for this behaviour is that you in fact, somehow, have two versions of react-query floating around. Both versions then do |
Beta Was this translation helpful? Give feedback.
-
Hi TkDodo, thank you for your response. The lib is 'managed by hand, and manually linked' with file symbolic links inside node_modules. The final app, based on React Create App, uses webpack internally. After a second thought, it may be that the
resolves to a different file (esm vs non-esm) than the
even if there is only one library version. Anway, I have decided to go to the solution to move all the hooks to the parent components, even at the price of duplicates for the time being, the long-term solution would be to update my library to have a proper setup with proper modules definitions as well. Thanks again for your time. |
Beta Was this translation helpful? Give feedback.
Hi TkDodo, thank you for your response.
The lib is 'managed by hand, and manually linked' with file symbolic links inside node_modules.
In 'final' components like in the index.ts, the import path resolves exactly to the file given above (the one that starts with "Object.defineProperty(...)").
The final app, based on React Create App, uses webpack internally.
After a second thought, it may be that the
resolves to a different file (esm vs non-esm) than the
even if there is only one library version.
Anway, I have decided to go to the solution to move all the hooks to …