Unable to use react-query when hooks are created in separate library

[SoftMemes]

Describe the bug

I have a monorepo with yarn 3 workspaces consisting of the following (as well as other components):

• contracts which uses Orval to create typed react-query hooks from OpenAPI
• ui, a next.js project that has a workspace dependency on contracts and is using above hooks

The only direct dependencies on react-query are through contracts, my UI project does not directly use react-query.

I'm now running into a few issues to do with module resolution, and am not sure how much of this relates to yarn, workspaces, react-query, or next magic.

React-query cannot find QueryProvider

If I make react-query a peer dependency of contracts, then initialize react-query in my next project (set a query provider, etc), then the hooks that use react-query under the hood from contracts do not find the QueryClient. It appears to "see" its own version of react-query even though this is a peer dependency of contracts and I provide it as a direct dependency in ui.

I am able to work around this by having contracts instead directly depend on react-query, and re-export the symbols from react-query (export * from 'react-query'). This appears to give the hooks in contracts` access to the same react-query and the context / query provider is found.

... or at least it was. Without any meaningful changes (I'm working on pinning down the exact change), I am no longer able to do it this way, as react-query now fails to find react. Inside the compiled code of react-query, I am getting React as an undefined symbol and this line blows up var defaultContext = /*#__PURE__*/React.createContext(undefined); iin react/QueryClientProvider.js

I appreciate that this isn't much to go on, but in general, what is the recommended method for providing custom hooks based on react-query in a library in terms of dependencies and configuration of the query client?

Your minimal, reproducible example

N/A

Steps to reproduce

1. Build a library that leverages react-query in custom hooks with react-query as a peer dependency
2. Use the library from above in a different project, providing react-query as a direct dependency
3. Configure react-query with a QueryClientProvider in the dom where the hooks from 1 are being used

Expected behavior

React-query can "see" the context and query provider wired up in the react DOM, even when using peer dependencies and the react-query library is provided as a dependency form the parent project.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Ubuntu 20
• Yarn: 3.2.0
• Next.js: 12.1.6

react-query version

3.39.0

TypeScript version

4.6.4

Additional context

No response

[mauris]

it's hard to tell what went wrong without knowing how your monorepo setup is like. I use nx for my monorepo setup, with the following packages:

• one React app (entrypoint and build)
• 3 React libraries, some of which provide custom hooks that compose useQuery, useQueries and useInfiniteQuery

I don't face the issue you've described on what I have:

• OSes: Windows (developer), macOS (developer), Debian (docker/k8s containers)
• react-query version: 3.39.0
• TypeScript version: 4.6.4

might be worthwhile for you to share the problem in a minimal reproducible setup

[TkDodo]

I appreciate that this isn't much to go on, but in general, what is the recommended method for providing custom hooks based on react-query in a library in terms of dependencies and configuration of the query client?

if you want a shared scope, meaning that the library uses the same context / client as the application that includes it, I would do it like you've described (I think):

• have the lib define react-query as peerDependency
• have the app create the queryClient and the QueryClientProvider.

the useQuery calls in the lib should just pick up that client. If that's not the case, you likely have either two versions of react-query or two versions of react around.

if you want an isolated scope, I would take a look at the custom context feature for v4.

[TkDodo]

Any updates here? Is this still an issue?

[nctay]

Having same issue with turborepo monorepo setup, extracting queries to different package causes it.

[TkDodo]

@nctay can you link to an example repo that has the issue please?

[petercpwong]

Having the same issue as well with a NextJS pnpm monorepo setup, even after upgrading to react-query v4. Had to pass in defaultContext to every single hook to get it to work. I'm also using next-transpile-modules so that could be what's causing the issue.

It works flawlessly with a vite pnpm monorepo setup though.

[stamahto]

I have same issue too

[TkDodo]

It's honestly not very helpful stating that you have the issue too without providing a minimal reproduction that we can look into. So far, no one has created a reproduction, so there is nothing I can look into.
I'm gonna close this now, feel free to reopen once you can share a reproduction.

[mverissimo]

I faced this issue too, you need to check if have the equal version of react and react-query and both packages.

[stamahto]

I faced this issue too, you need to check if have the equal version of react and react-query and both packages.

I do, still not working. I´m gonna have to learn publishing packages into npmjs and create reproduction case. It will take me some time, but I hope it will be worthy.

[SoftMemes]

Hi,

Not a repro, and I'm travelling so will be a brief message from the phone, but I know at least what caused this now. Using yarn 3 with a pnpm style repo (this may apply to other setups but this is where I've seen it), a dependency will only be shared if it matches exactly. This means that the same version has to be resolved which is easy enough to guarantee with version ranges but also critically, the same dependencies need to have been resolved.

This interacts with in particular dev dependencies. If the project A dependends on library B, both which use a third party package C (for example react query), but A and B have direct dependencies in such a way that the dev dependencies of C are fulfilled by different versions, then A and B will see different instances of C.

The way to check this is to compare where the symlink for C is pointing in node modules for A vs B, the compare the node modules in turn for the instance of C used by A vs C used by B, and tweak dependencies of each until they match perfectly.

[marissync]

Having the same issue as well with a NextJS pnpm monorepo setup, even after upgrading to react-query v4. Had to pass in defaultContext to every single hook to get it to work. I'm also using next-transpile-modules so that could be what's causing the issue.

It works flawlessly with a vite pnpm monorepo setup though.

How did you do that? Facing same issue in next.js

[petercpwong]

@marissync The useQuery hook accepts a context option. Just pass in the defaultContext exported by react query.

import { defaultContext, useQuery } from '@tanstack/react-query';

useQuery({ context: defaultContext });