Support variable patterns in allowlist for @tanstack/query/exhaustive-deps

[foxable]

I'm using TanStack Query in a project with lots of different API clients. The usual pattern for queries is:

constuserApi=useUserApi();useQuery({queryKey: ["getUsers"],queryFn: ()=>userApi.getUsers(),});

@tanstack/query/exhaustive-deps forces me to to add userApi to queryKey, which is neither possible nor intended in this scenario. allowlist.variables allows me to ignore the userApi variable. However, this is not viable in my project, because there are lots of different API clients, and I want to avoid extending the ESLint rule whenever a new client is added. Also, I don't want to use a generic variable name like api, because I prefer using specific names for API clients.

That's why I suggest to add an option, e.g. named variablePatterns, which allows to define patterns for ignored variables as an alternative to static string values.

Here is an example of how the rule could be configured in my project:

"@tanstack/query/exhaustive-deps": ["error",{allowlist: {"variablePatterns": ["*Api"],}}]

[ryanportfolio]

I don't think there's any pattern support for this right now. The allowlist.variables list is just checked as an exact match (the names go into a Set and the rule checks if your variable name is in it), so "*Api" would only match a variable actually named *Api, not anything ending in Api. And variablePatterns isn't ideal, the config schema is locked down to just variables and types, so it'll throw a validation error rather than quietly ignore it.

The closest thing that already exists is allowlist.types. so if you've got allowlist.variables, you've got this too. Instead of the variable name, it ignores a variable based on its TypeScript type:

"@tanstack/query/exhaustive-deps": ["error",{allowlist: {types: ["ApiClient"],},}]

Couple of catches though. It matches on the type's name, and I think it only looks at an explicit annotation on the variable, not an inferred type. So you'd have to write it like const userApi: ApiClient = useUserApi() for it to notice.

If all your clients happen to share one type then this is probably what you want, you set it once and never touch the config again when a new client shows up. But if each client is its own separate type with no shared name, then honestly types is about as much work as just listing every variable, and there's no glob to fall back on. So for the naming-convention case I think the feature request still makes sense.

[foxable]

Thanks for your input. I did evaluate allowlist.types as an alternative for my scenario, but unfortunately it is not applicable either, because there is no shared type which all API clients in my project have in common. So as you already mentioned, either I would have to continuously maintain variables or types when new API clients are added to the project. Since this a project with lots of different developers involved, this is not feasible. So having a way to specify a naming convention for ignored variables (or types) would provide more flexibility and enable the described use case.

[TkDodo]

I’ve come to think that we have been too strict with this. I tried to find situations where function calls lead to stale closures but couldn’t reproduce any :/ It would mostly occur if you have two usages where a function call would produce different outcomes, which isn’t very likely.

With that in mind, I think we should revert the parts of this PR that are handling function calls:

• fix: improve exhaustive dependencies detection #10258

There’s also Promise .then() that we would likely need to keep checking but not general function calls. We can keep the allowList because it serves a general purpose.

@Newbie012 what do you think?

[Newbie012]

Yeah, let's loosen it back

[Newbie012]

raised a change in #11067