eslint-plugin-query[exhaustive-deps]: Inconsistent false positives asking for `queryClient` to be a dependency, when passed into helper functions

[alythobani]

Describe the bug

When refactoring parts of the queryFn used in useQuery (or queryOptions) into helper functions that involve queryClient, exhaustive-deps will sometimes error on the queryKey thinking that queryClient should be included in it. It's hard to know what's the differentiator for when exhaustive-deps thinks queryClient should be a dependency or not; some helper functions involving queryClient don't trigger the error, while others do.

Your minimal, reproducible example

Typescript Playground

Steps to reproduce

1. Build a useQuery whose queryFn uses a queryClient, e.g. in the TS Playground example, to only fetch items that aren't already cached, and individually cache them (this is related to Keys for array of items #712)
2. Refactor out helper functions for the (get from cache) and (individually cache) portions of the queryFn, as seen in the TS Playground example
3. See the inconsistent behavior of exhaustive-deps as shown in the playground example(s)

Expected behavior

No errors asking for queryClient to be a dep in queryKey; or at least consistent behavior. But ideally a way to refactor out helper functions (for the sake of clean code) without errors.

How often does this bug happen?

Sometimes

Screenshots or Videos

getAlreadyCachedItems: error

No helpers: no error

individuallyCacheItem: no error

individuallyCacheItems: error

Platform

• MacOS, but shouldn't be relevant

Tanstack Query adapter

None

TanStack Query version

5.81.2

TypeScript version

5.7.2

Additional context

No response

[TkDodo]

No errors asking for queryClient to be a dep in queryKey

The errors are fine. I think queryClient used to be an exception, but it’s not anymore, because we now inject the client into the queryFn. So instead of closing over it from useQueryClient, you can just do:

queryFn: ({ client }) => ...