TanStack Query ships one package per framework, and the README documents no defaults

The core ships apart from the framework adapters

There is no single TanStack Query package, and the repository description says so by listing them: React Query, Solid Query, Svelte Query and Vue Query, with TS/JS as the substrate. The badge at the top of the page points at @tanstack/query-core, which is the framework-agnostic piece, and each framework adapter is a separate package built on it. The examples directory follows the same split, with one example app per framework: react, vue, solid, svelte, preact, angular and lit. Two consequences for a team. You install the adapter matching your framework rather than a library, so the import path tells you which one you are on. And the page does not describe any shared cache between adapters, so treat each framework's client as its own thing rather than assuming state crosses the boundary.

Releases arrive as dated snapshots and per-package versions

Look at the release list before you write a version range. The three most recent tags are two dated snapshot releases, release-2026-09-26-0357 and release-2026-09-26-0017, published within minutes of each other on 2026-09-26, and a per-package version, @tanstack/[email protected]. Two versioning schemes in one list, which means the tag you can see in a dashboard is not necessarily the version string that belongs in your manifest. Snapshot tags are convenient for reproducing a build at a moment in time and useless as a range, because there is no semver ordering to express. The per-package version is what a consumer pins. The last push to the default branch is dated 2026-09-29, so the branch moves daily and the tagged snapshot is the only fixed point in the list.

The test script runs eight Nx targets, not just unit tests

The root manifest pins the package manager and the engine floor:

"packageManager": "[email protected]",
"engines": {
  "pnpm": ">=12.4.2"
},

and the test entry point is a single Nx run across eight targets:

nx run-many --targets=test:sherif,test:knip,test:docs,test:eslint,test:lib,test:types,test:build,build

That list is the real shape of the project. sherif checks package.json consistency across ./integrations/* and ./examples/*, knip runs twice including a strict pass for unlisted dependencies, test:docs is node scripts/verify-links.ts, and the remainder cover linting, library tests, types and builds. Building the repository means having Nx, pnpm at that version and the whole workspace, which is why a library you install as a single dependency is developed in a monorepo you would never run yourself.

Bundle size is a gate, and React is counted as external

A .size-limit.json file at the root, a size-limit test target, and a bundle size badge in the README add up to the same statement: the shipped weight of this library is checked in CI rather than left to reviewers. The badge is a bundlejs link whose configuration lists react and react-dom as external, so the number it reports measures this library and deliberately excludes the framework. That distinction matters when you read a bundle figure for TanStack Query, because the honest comparison is library-against-library, not application-against-application. The flip side for a contributor is that a change which grows the bundle is a build failure rather than a review comment, and a feature request that adds weight has to justify itself against an existing budget.

Four bullets, and no default documented anywhere on the page

The entire feature claim is one sentence and four bullets: an async state management library built to simplify fetching, caching, synchronizing and updating server state; protocol-agnostic fetching for REST, GraphQL and promises; caching, refetching, pagination and infinite scroll; mutations, dependent queries and background updates; prefetching, cancellation and React Suspense support. Read that as a table of contents. The page does not state how long data stays fresh, whether a failed request is retried, when a refetch fires after a window regains focus, or what happens to a query that errors, because none of those defaults are on it. Everything after the first paragraph is a link to tanstack.com/query, so the decisions your team will argue about are documented off-page and have to be read before the first query is written.

Protocol-agnostic leaves the network layer to you

The first bullet says protocol-agnostic fetching, then names REST, GraphQL and promises, then adds etc. The etc. is where the scope ends, and it is worth being precise about what the claim does and does not buy you. It means the library is not tied to a particular wire protocol, so a GraphQL endpoint and a REST endpoint can sit in the same app without two different data layers. It does not mean a client ships with it. The page names no transport, no HTTP wrapper, no request interceptor and no default fetcher, so the network code stays in your codebase and the library works on top of whatever you return. That also means retry, authentication headers, request cancellation and error shapes are your decisions, made in code you own, against behaviour the README does not describe.

AI_POLICY.md and CONTRIBUTING.md sit beside the sponsor links

The tree carries files the README never mentions: AI_POLICY.md, AGENTS.md, FUNDING.json, .coderabbit.yaml and a knip.ts at the root, alongside CONTRIBUTING.md which the page does point to for setup instructions. The practical advice is narrow and cheap to follow. Read AI_POLICY.md before opening a pull request, because the page gives no summary of what it permits, and read CONTRIBUTING.md before the first branch, because that is the only setup path named. Funding runs through GitHub Sponsors for the maintainer, and the partners section carries two logos, a recruitment line for TanStack Query Partners and a partnership mailbox, so the commercial relationships around the project are visible on the front page while the contribution rules are one file deeper.

Editorial conclusion

Adopt TanStack Query when server state is a real part of your app and the alternative is hand-rolled cache maps with loading and error flags in every component. Do not adopt it expecting the README to tell you how it behaves, because the page is four capability bullets and a link, and every default you will argue about later lives in the documentation. Verify four things before you commit. Install the adapter for your framework and check whether the shared core package, published as @tanstack/query-core, is what you want to depend on directly. Pin the adapter version rather than the repository, since releases arrive both as per-package versions and as dated snapshot tags. Read the integration and examples directories if you are on anything other than React, Vue, Solid or Svelte, because those are the frameworks with example apps in the tree. And read AI_POLICY.md and CONTRIBUTING.md before opening a pull request, since the README points only at the contributing setup instructions and says nothing about either policy.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes