Reviewing files that changed from the base of the PR and between 411f030 and 46d274c.

• .changeset/wise-suns-ask.md (1 hunks)
• packages/query-core/src/__tests__/queryClient.test-d.tsx (2 hunks)
• packages/query-core/src/__tests__/queryClient.test.tsx (9 hunks)
• packages/query-core/src/queryClient.ts (6 hunks)
• packages/vue-query/src/queryClient.ts (1 hunks)

packages/query-core/src/queryClient.ts (5)

140-159: LGTM! ensureQueryData correctly delegates to the new query method.

The internal delegation to query with staleTime: 'static' maintains the expected behavior while utilizing the new method.

---

336-365: Verify alignment with maintainer expectations regarding API migration strategy.

Per TkDodo's comment, the original intent was to "add new methods and deprecate the old ones to avoid a breaking change, not to remove/rename them outright." While this implementation maintains backward compatibility by keeping fetchQuery as a wrapper, please confirm that making query the primary implementation (rather than keeping fetchQuery as primary and adding query as an alias) aligns with the team's migration strategy.

---

384-393: LGTM! prefetchQuery correctly delegates to the new query method.

The delegation pattern with .then(noop).catch(noop) properly maintains the fire-and-forget prefetch behavior.

---

395-417: LGTM! infiniteQuery implementation is clean and consistent.

The method correctly sets the infiniteQueryBehavior and delegates to the query method. The type assertion on line 416 is necessary due to the behavior transformation.

---

436-452: LGTM! prefetchInfiniteQuery correctly delegates to the new infiniteQuery method.

The delegation pattern maintains the fire-and-forget prefetch behavior.

packages/query-core/src/__tests__/queryClient.test-d.tsx (1)

313-328: LGTM! Type assertions for new methods are comprehensive and correct.

The type checks for query and infiniteQuery methods properly cover both fully typed and untyped scenarios, maintaining consistency with the existing test structure.

Also applies to: 462-477

packages/query-core/src/__tests__/queryClient.test.tsx (1)

11-11: LGTM! Comprehensive test coverage for the new query methods.

The test additions are excellent:

• Properly imports noop utility for prefetch patterns
• Marks old test suites with @deprecated comments for clarity
• Provides thorough coverage of new query and infiniteQuery methods including:
  • Static staleTime behavior
  • Prefetching scenarios
  • Type safety validation
  • Edge cases (cache hits, invalidation, GC, etc.)
• Maintains parallel structure with legacy tests while validating new functionality

Also applies to: 453-453, 529-620, 622-622, 683-720, 753-753, 928-1100, 1102-1102, 1147-1189, 1191-1191, 1281-1374, 1376-1376, 1426-1477

packages/vue-query/src/queryClient.ts (1)

256-346: LGTM! Vue Query extensions for new methods are well-implemented.

The query and infiniteQuery methods properly:

• Provide overloads for both plain and MaybeRefDeep options
• Use cloneDeepUnref to handle Vue's reactive refs correctly
• Delegate to the parent QueryClient implementation
• Follow the established pattern used by other methods in this class

Reviewing files that changed from the base of the PR and between 16bed21 and fb9dcdc.

• .changeset/famous-owls-battle.md (1 hunks)
• packages/query-core/src/__tests__/queryClient.test-d.tsx (7 hunks)
• packages/query-core/src/__tests__/queryClient.test.tsx (9 hunks)
• packages/query-core/src/queryClient.ts (8 hunks)
• packages/query-core/src/types.ts (3 hunks)
• packages/react-query/src/__tests__/infiniteQueryOptions.test-d.tsx (3 hunks)
• packages/react-query/src/__tests__/queryOptions.test-d.tsx (2 hunks)
• packages/vue-query/src/queryClient.ts (2 hunks)

• packages/react-query/src/tests/queryOptions.test-d.tsx
• packages/react-query/src/tests/infiniteQueryOptions.test-d.tsx

• GitHub Check: Test

packages/query-core/src/__tests__/queryClient.test-d.tsx (7)

161-172: LGTM!

The test correctly verifies that fetchQuery does not accept the select option, maintaining backward compatibility as intended in the PR design.

---

174-227: LGTM!

The tests correctly verify:

• select option is not allowed on fetchInfiniteQuery (backward compatibility)
• pages parameter is properly typed
• getNextPageParam is required when pages is specified

---

229-239: LGTM!

The test correctly verifies that the new query method accepts the select option, which is the key differentiator from the fetchQuery compatibility wrapper.

---

242-257: Verify whether select should be allowed on infiniteQuery.

This test asserts that select is not allowed on infiniteQuery, but:

1. Lines 336-339 show InfiniteQueryExecuteOptions being used with a select option successfully
2. Unlike the fetchInfiniteQuery test (line 183), there's no @ts-expect-error annotation on the select property (line 249)

Based on the implementation where infiniteQuery delegates to query (which supports select), it appears select should be allowed. Please clarify the intended behavior and add the @ts-expect-error annotation if select is truly not supported, or update the test description if it is supported.

---

428-429: LGTM!

The type check correctly verifies that query returns the expected TData type.

---

578-579: LGTM!

The type check correctly verifies that query returns unknown when called with untyped options.

---

583-593: LGTM!

The type checks correctly verify the return types for fetchInfiniteQuery and infiniteQuery with untyped options, both returning InfiniteData<unknown, unknown>.

Reviewing files that changed from the base of the PR and between fb9dcdc and 3b33d44.

• .changeset/famous-owls-battle.md (1 hunks)
• packages/query-core/src/__tests__/queryClient.test-d.tsx (7 hunks)

• .changeset/famous-owls-battle.md

• GitHub Check: Preview
• GitHub Check: Test

Reviewing files that changed from the base of the PR and between 3b33d44 and a24433b.

• packages/query-core/src/__tests__/queryClient.test-d.tsx (7 hunks)

• GitHub Check: Test
• GitHub Check: Preview

packages/query-core/src/__tests__/queryClient.test-d.tsx (5)

13-13: LGTM!

The addition of InfiniteQueryExecuteOptions to the imports aligns with the new public API surface introduced in this PR.

---

161-172: LGTM!

This test correctly validates that the legacy fetchQuery method does not support the select option, with proper use of @ts-expect-error to enforce the type constraint.

---

174-227: LGTM!

The tests for fetchInfiniteQuery correctly validate the legacy behavior, including:

• Properly rejecting select option with @ts-expect-error
• Validating the pages option with correct type expectations
• Enforcing required parameter constraints

---

229-239: LGTM!

This test correctly validates that the new query method supports the select option for data transformation, properly demonstrating the enhanced functionality compared to the legacy fetchQuery.

---

328-336: LGTM!

The integration of the new query and infiniteQuery methods into the fully-typed and untyped test sections is correct:

• Proper usage of InfiniteQueryExecuteOptions<TData, TError> type
• Correct type expectations for return values
• Good coverage of both typed and untyped variants

Also applies to: 422-423, 434-435, 569-570, 581-584

Reviewing files that changed from the base of the PR and between a24433b and fa6f86f.

• packages/query-core/src/__tests__/queryClient.test-d.tsx (7 hunks)
• packages/query-core/src/types.ts (3 hunks)

• GitHub Check: Test
• GitHub Check: Preview

packages/query-core/src/types.ts (3)

491-509: LGTM: QueryExecuteOptions introduces select support correctly.

The new QueryExecuteOptions interface properly introduces the select transformation flow via the TQueryData generic. The data flows as TQueryFnData (raw) → TQueryData (intermediate) → TData (final via select). The staleTime correctly uses TQueryData since staleness should be determined from the query's stored data, not the transformed result.

---

511-528: LGTM: FetchQueryOptions maintains backward compatibility.

The refactor to make FetchQueryOptions an alias that omits select from QueryExecuteOptions is correct. Passing TData as both the 3rd and 4th generics (TData, TData) ensures no transformation layer exists when select is omitted, maintaining the original behavior of fetchQuery.

---

568-586: LGTM: InfiniteQueryExecuteOptions properly extends execute options.

The type correctly:

• Omits initialPageParam from QueryExecuteOptions (which has initialPageParam?: never)
• Re-adds it via InitialPageParam<TPageParam> with the proper type
• Uses InfiniteData<TQueryFnData, TPageParam> as the intermediate data shape
• Includes InfiniteQueryPages discriminated union to enforce the pages/getNextPageParam constraint

packages/query-core/src/__tests__/queryClient.test-d.tsx (4)

161-172: LGTM: Correctly verifies fetchQuery rejects select.

The test properly uses @ts-expect-error to confirm that the legacy fetchQuery method does not support the select option, maintaining backward compatibility.

Based on learnings.

---

229-239: LGTM: Correctly verifies query accepts select.

The test confirms that the new query method supports the select option for data transformation, using assertType (without @ts-expect-error) to validate this is allowed.

Based on learnings.

---

241-257: LGTM: Correctly verifies infiniteQuery accepts select.

The test confirms that the new infiniteQuery method supports the select option for transforming infinite query data, using assertType (without @ts-expect-error) to validate this is allowed.

Based on learnings.

---

328-336: LGTM: infiniteQueryOptions properly typed.

The variable correctly uses InfiniteQueryExecuteOptions<TData, TError> with defaults for remaining generics. The getNextPageParam callback properly receives lastPage typed as TData.

Reviewing files that changed from the base of the PR and between fa6f86f and 6a3c2ed.

• packages/query-core/src/queryClient.ts (5 hunks)
• packages/query-core/src/types.ts (3 hunks)

• GitHub Check: Test

packages/query-core/src/types.ts (2)

491-509: LGTM! Well-designed interface for query execution options.

The interface correctly separates TQueryData from TData to enable optional select transformation, explicitly prevents initialPageParam for single queries, and provides clear documentation for staleTime behavior.

---

561-586: LGTM! Clean type composition for infinite query execution.

The discriminated union for InfiniteQueryPages and the composition strategy for InfiniteQueryExecuteOptions (omitting the never field then adding the required version) correctly enforces that infinite queries must provide initialPageParam.

packages/query-core/src/queryClient.ts (2)

343-384: LGTM! Core query execution logic is sound.

The method correctly handles stale-time checking, optional data fetching, and select transformation. The double cast as unknown as TData on line 383 is a TypeScript workaround when no select is provided (TData defaults to TQueryData), though it's safe in practice.

---

452-468: Fix: Missing options.behavior setup before delegation to fetchQuery.

The fetchInfiniteQuery method must set options.behavior before delegating to fetchQuery, matching the pattern used in infiniteQuery (lines 443-448) and ensureInfiniteQueryData (lines 503-508). Without this, infinite query pagination will not work correctly.

 fetchInfiniteQuery<
   TQueryFnData,
   TError = DefaultError,
   TData = TQueryFnData,
   TQueryKey extends QueryKey = QueryKey,
   TPageParam = unknown,
 >(
   options: FetchInfiniteQueryOptions<
     TQueryFnData,
     TError,
     TData,
     TQueryKey,
     TPageParam
   >,
 ): Promise<InfiniteData<TData, TPageParam>> {
+  options.behavior = infiniteQueryBehavior<
+    TQueryFnData,
+    TError,
+    TData,
+    TPageParam
+  >(options.pages)
   return this.fetchQuery(options as any)
 }

⛔ Skipped due to learnings

Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.071Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.

Reviewing files that changed from the base of the PR and between 6a3c2ed and 1338e8e.

• packages/query-core/src/queryClient.ts (5 hunks)

packages/query-core/src/queryClient.ts (2)

28-28: LGTM!

The new type imports support the query and infiniteQuery method signatures correctly.

Also applies to: 37-37

---

373-383: Verify data handling assumptions in the query method implementation.

The technical concerns in the review are valid: when isStale is false, query.state.data could be undefined (initialized without initialData), and this would be passed to the select function without a guard. The type signature select?: (data: TQueryData) => TData expects defined data, but the cast on line 375 (as TQueryData) doesn't guarantee it at runtime.

However, test cases across the codebase show select always receives properly typed, defined data—no scenario in tests passes undefined to the selector. This suggests either:

1. The scenario is prevented by caller contracts (e.g., always providing initialData or ensuring fetch completes first)
2. The stale-time logic prevents isStale=false when data is undefined
3. This is an edge case not covered by tests

Confirm whether adding a guard (e.g., if (!queryData) return queryData as TData) is necessary, or if the current design intentionally relies on caller responsibility to provide valid initial state.

Reviewing files that changed from the base of the PR and between 1338e8e and 8c46d9e.

• .changeset/famous-owls-battle.md (1 hunks)
• packages/query-core/src/__tests__/queryClient.test-d.tsx (7 hunks)
• packages/query-core/src/__tests__/queryClient.test.tsx (9 hunks)
• packages/query-core/src/queryClient.ts (5 hunks)
• packages/query-core/src/types.ts (3 hunks)
• packages/react-query/src/__tests__/infiniteQueryOptions.test-d.tsx (3 hunks)
• packages/react-query/src/__tests__/queryOptions.test-d.tsx (2 hunks)
• packages/vue-query/src/queryClient.ts (2 hunks)

• .changeset/famous-owls-battle.md

• GitHub Check: Test

packages/query-core/src/types.ts (1)

491-509: New execute option types align well with observer options and infinite semantics

QueryExecuteOptions and InfiniteQueryExecuteOptions are wired correctly: using TQueryData for staleTime and select matches how defaultQueryOptions and resolveStaleTime operate, and InfiniteQueryPages cleanly enforces the pages/getNextPageParam pairing while being reused by both execute and fetch infinite options. This should give query/infiniteQuery the right type-level behavior without impacting existing Fetch* callers.

Also applies to: 561-587, 588-605

packages/react-query/src/__tests__/queryOptions.test-d.tsx (1)

58-66: query vs fetchQuery select behavior is well covered

The added tests clearly distinguish the new query API (including select transformations) from the legacy fetchQuery (which returns the raw number even when given options that contain select). This matches the intended separation between the new and old imperative entry points.

Also applies to: 76-95

packages/query-core/src/__tests__/queryClient.test-d.tsx (2)

161-172: Type tests cleanly separate select support between legacy and new APIs

The new blocks for fetchQuery, fetchInfiniteQuery, query, and infiniteQuery correctly encode the contract:

• fetchQuery/fetchInfiniteQuery reject select at the option level via @ts-expect-error.
• query/infiniteQuery accept select and assert the transformed data types.

This gives solid type-level coverage for the migration story from the old fetch* APIs to the new imperative methods.

Also applies to: 175-192, 229-257

---

193-203: Infinite execute/fetch options generics are exercised thoroughly

The updated tests around passing pages, using { count: number } pages, and the “fully typed usage” blocks validate that:

• FetchInfiniteQueryOptions and InfiniteQueryExecuteOptions expose lastPage as TData in getNextPageParam.
• infiniteQuery and fetchInfiniteQuery both resolve to InfiniteData<TData, TPageParam> (or InfiniteData<unknown, unknown> in the untyped case).

This gives good confidence that the new infinite-execute types integrate correctly with QueryClient’s generics.

Also applies to: 259-269, 328-337, 422-435, 569-585

packages/query-core/src/__tests__/queryClient.test.tsx (2)

529-620: Static staleTime behavior for query/infiniteQuery is well specified

The new “with static staleTime” suites for both query and infiniteQuery clearly pin down the behavior:

• Cached data (including falsy values) is returned without re-fetching when staleTime is 'static'.
• Missing queries invoke queryFn once.
• Providing initialData short-circuits network calls.
• A second call with staleTime: 0 drives an explicit background revalidation, as verified via noop and cache assertions.

This is a strong regression suite for the new imperative surface.

Also applies to: 683-720

---

928-1106: Runtime tests give good confidence in new query/infiniteQuery entry points

The added query/infiniteQuery suites (including “used for prefetching”) thoroughly mirror the legacy fetchQuery/prefetch* behavior:

• No-retry-by-default semantics, gcTime handling, and static staleTime cache hits are preserved.
• Infinite flows still produce the expected InfiniteData shapes, including multi-page prefetch and early termination via getNextPageParam.
• Prefetch-style usages (.catch(noop)) ensure that using query/infiniteQuery purely for seeding the cache continues to work.

Overall, the tests look well aligned with the intended migration path from the deprecated fetch* methods to the new APIs.

Also applies to: 1153-1195, 1287-1380, 1432-1483

packages/vue-query/src/queryClient.ts (1)

19-37: Vue QueryClient query/infiniteQuery wrappers are consistent and type-safe

The new query and infiniteQuery overloads:

• Reuse the core QueryExecuteOptions / InfiniteQueryExecuteOptions generics correctly.
• Preserve the Vue adapter’s MaybeRefDeep + cloneDeepUnref pattern so refs and getter-based queryKeys are handled before delegating.
• Return the expected Promise<TData> / Promise<InfiniteData<TData, TPageParam>> types, matching the core client.

This keeps the Vue surface in lockstep with the new imperative APIs.

Also applies to: 258-366

packages/query-core/src/queryClient.ts (1)

343-384: query implementation correctly layers select on top of legacy fetch semantics

The new query method:

• Runs through defaultQueryOptions, preserves the “no retry by default” behavior from fetchQuery, and uses resolveStaleTime with QueryExecuteOptions.staleTime typed on TQueryData.
• Fetches when isStaleByTime is true, otherwise returns query.state.data from cache.
• Applies select once, purely at the imperative layer, without mutating the stored query data.

This matches the intended contract for the new imperative API and is well covered by the added runtime and type tests.

Reviewing files that changed from the base of the PR and between 8c46d9e and a16e585.

• packages/query-core/src/queryClient.ts (4 hunks)
• packages/query-core/src/types.ts (3 hunks)
• packages/vue-query/src/queryClient.ts (2 hunks)

• GitHub Check: Preview
• GitHub Check: Test

packages/query-core/src/queryClient.ts (1)

343-384: LGTM! The query method logic is sound.

The implementation correctly:

• Defaults retry to false (matching fetchQuery behavior)
• Checks staleness via resolveStaleTime
• Fetches when stale or returns cached data
• Applies select transformation when provided

The double cast at Line 383 (as unknown as TData) is safe given that TData defaults to TQueryData when select is not provided, though it's overly defensive.

Based on learnings, the new query method correctly supports the select option for data transformation.

packages/query-core/src/types.ts (1)

491-509: LGTM! Type definitions are well-structured.

The new type definitions are correctly designed:

• QueryExecuteOptions (491-509): Properly extends QueryOptions with required queryKey, adds select for data transformation, and includes staleTime for staleness control
• InfiniteQueryPages (561-566): Clean discriminated union that allows optional pages specification or requires getNextPageParam when pages are specified
• InfiniteQueryExecuteOptions (568-586): Well-composed type combining QueryExecuteOptions, InitialPageParam, and InfiniteQueryPages
• FetchInfiniteQueryOptions (605): Updated to reuse InfiniteQueryPages, improving consistency

Based on learnings, the new types correctly support the select option for data transformation in query and infiniteQuery methods.

Also applies to: 561-586, 605-605