eslint-plugin-query: no-unstable-deps incorrectly treats inherited Object.prototype properties as tracked custom hooks

[kprakhar]

Describe the bug

@tanstack/eslint-plugin-query's no-unstable-deps rule performs property lookups on trackedCustomHooks using:

trackedCustomHooks[callExpression.callee.name]

Since trackedCustomHooks is a plain object, inherited Object.prototype properties such as toString, constructor, and valueOf are returned instead of undefined.

As a result, unrelated functions with these names can be treated as tracked TanStack Query hooks, causing false positives from no-unstable-deps.

Your minimal, reproducible example

https://stackblitz.com/edit/vitejs-vite-mwhrnhuz?file=src%2FApp.tsx

Steps to reproduce

1. Enable the @tanstack/query/no-unstable-deps rule.
2. Import a function whose name matches an inherited Object.prototype property, for example toString from Lodash.
3. Use it to derive a value and include that value in a React hook dependency array.

import { toString } from 'lodash'

const sessionId = toString(router.query.sessionId)

useCallback(() => {
  console.log(sessionId)
}, [sessionId])

4. Run ESLint.

Expected behaviour

The rule should only treat explicitly tracked custom hooks as tracked hooks.

Inherited Object.prototype properties should not be considered, so the example above should not produce a no-unstable-deps warning.

Use an own-property check before reading from trackedCustomHooks, for example:

return Object.hasOwn(trackedCustomHooks, calleeName)
  ? trackedCustomHooks[calleeName]
  : undefined

How often does this bug happen?

Everytime

Screenshots or Videos

No response

Platform

ESLint: v10.x
@tanstack/eslint-plugin-query: 5.101.4

Tanstack Query adapter

None

TanStack Query version

5.101.4

TypeScript version

No response

Additional context

I've opened a PR with a proposed fix and regression tests:

PR: #11117

[skdas20]

Reproduced with the StackBlitz example — the toString-from-lodash case flags exactly as described. The Object.hasOwn guard you suggest looks like the right shape; the same unguarded lookup pattern is worth auditing anywhere else the rule reads user-derived names off plain objects. I'd like to take this: PR with the own-property check plus rule tests covering toString/constructor/valueOf callees (and a null-prototype option as belt-and-braces if maintainers prefer that instead).

[kprakhar]

Thanks for reproducing it! I actually have a PR open with the Object.hasOwn fix and regression tests covering the inherited Object.prototype property names: #11117. Happy to update it further if maintainers would prefer a broader audit of similar lookup patterns or a different approach (e.g. null-prototype option).

[skdas20]

@kprakhar thanks for the heads-up — #11117 was already open before I commented, so I'll stand down on this one. No need for a competing PR.