# TanStack Store: one immutable core with per-framework adapters

> TanStack Store is a small reactive store for TypeScript applications, kept deliberately framework agnostic and paired with adapters for React, Solid, Vue, Angular, Svelte, Lit and Octane. It is the piece other TanStack packages sit on, and the part to judge is how thin the repository itself is, since the public API documentation lives off the repository.

**TanStack/store** — 🤖 Framework agnostic, type-safe store w/ reactive framework adapters

- Repository: https://github.com/TanStack/store
- Website: https://tanstack.com/store
- Stars: 911 · Forks: 118
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/tanstack-store

## A shared core instead of a state library owned by a framework

TanStack Store is described as an immutable, reactive data store with framework adapters, and the framing matters more than the feature list. Most state libraries are tied to one rendering model, so adopting one in a codebase with mixed React and Vue components means maintaining two state systems. The design here is the opposite: one store implementation, plus thin adapters that connect it to each framework's reactivity. The repository description calls it framework agnostic and type safe, and the README positions it as the piece that powers the core of the wider TanStack ecosystem, lightweight and standalone enough to drop into any application or use as a foundation inside a library you publish yourself. The stated selling points are fine-grained updates for state management and flexible primitives for building custom state logic, rather than a large fixed feature set you have to accept or work around.

## The repository documents the ecosystem, not the store API

Here is the first thing to understand about this project: the repository is a map, not a manual. The README carries a short description, a link to the documentation site at tanstack.com/store, badges for npm downloads, bundle size and releases, a section inviting contributors to issues, pull requests, GitHub discussions and Discord, and a partner section. The actual API reference sits in the hosted documentation rather than in the tree, and the repository does include a `docs/` directory plus a `typedoc.json` configuration and a `generate-docs` script, so generated reference pages are part of the workflow. The practical consequence for evaluation is that you cannot judge this project by reading its repository alone. Reading the tree tells you about the build system, the adapters and the release cadence. Learning the API means leaving the repository, and that is a real cost when you are comparing a candidate state library against another.

## A pnpm workspace orchestrated by Nx, not a single package

The repository is a monorepo with packages published from one tree. The root `package.json` pins pnpm as the package manager and declares the required pnpm version range, and the tree includes `pnpm-workspace.yaml`, `pnpm-lock.yaml`, an `nx.json` directory of Nx configuration and a `packages/` directory holding the actual published code. The build and test surface is run through Nx rather than npm scripts alone, and the root scripts show the shape of the checks. A representative slice of the declared scripts reads like this:

```json
  "scripts": {
    "test": "pnpm run test:ci",
    "test:ci": "nx run-many --targets=test:sherif,test:knip,test:eslint,test:lib,test:types,test:build,build",
    "test:eslint": "nx affected --target=test:eslint",
```

For contributors that means affected-only runs, since the `test:pr` and `build` scripts are Nx affected commands, and linting, knip, sherif, type checks and build checks all run as separate targets. The declared package manager and its version constraint are:

```json
  "packageManager": "pnpm@12.10.1+sha512.ba40a37eb1a370d60fea8c4cf1d364c13bcccef518e98ad2bcee954f539d38da37458e58261a3fa55e06523450ea0ffff9f497b135be41f2c15c1642bacace6c",
  "engines": {
    "pnpm": ">=11.28.5"
  },
```

If you are only consuming the packages, none of this touches you. If you plan to patch it, you are signing up for pnpm, Nx, knip, sherif and Prettier in one repository.

## Eight example apps keep the adapters honest

The `examples/` directory is the most useful part of the tree for judging the adapter story, and it is worth reading before you commit. It contains separate example applications for angular, lit, octane, preact, react, solid, svelte and vue, which is a wider set than the seven frameworks named in the README, since Preact and Angular both appear there. That spread tells you two things. The adapters are exercised against real renderers rather than a single reference environment, and the framework list in the README is not a marketing claim bolted onto one integration. The published packages follow the same naming, with scoped package names such as `@tanstack/react-store`, `@tanstack/vue-store` and `@tanstack/svelte-store` appearing in the release history. The core package is `@tanstack/store`, linked from the README to its npm listing and to a bundle size badge. What the repository does not give you is a comparison of the adapters to each other, so if you plan to run React and Vue against the same store, the examples are where you check how each one binds.

## The release history shows adapters at different maturity levels

The most concrete signal in the repository is the version spread across packages, and it is uneven. The three most recent releases are `@tanstack/vue-store@1.0.0-alpha.0` and `@tanstack/react-store@1.0.0-alpha.0`, both published on 2026-10-10, and `@tanstack/svelte-store@0.12.3` on 2026-10-09. Read that carefully: two of the adapters are at an alpha of a 1.0 line, and the Svelte adapter is on a 0.x release. An alpha tag on a 1.0.0 line is a signal that the API is expected to settle but has not yet been declared stable, and it means a caret range pointing at that alpha will move as the tag changes. Svelte being on 0.12.3 while React and Vue are on 1.0.0 alphas suggests different maturity histories per adapter rather than one shared release train. If your application depends on a specific adapter, pin it and read that adapter's changelog, because upgrading the core package alone may not be the upgrade that matters for your framework.

## Where Store sits against Query, Form and DB

The ecosystem map in the README is short and functional, and it is the fastest way to understand what this package is for. TanStack Query is listed as async state and caching, TanStack Form as type-safe form state, TanStack DB as a reactive sync client store, TanStack Pacer as debouncing, throttling and batching, TanStack Router as type-safe routing with URL state, TanStack Table as headless datagrids, and TanStack DevTools as a unified devtools panel. The distinction that matters for a reader choosing between them is between state that lives on the server and state that lives in the client. Query owns the async half, where data arrives, is cached and is refetched. Store owns the synchronous half, the reactive data your components read and write directly, including data that Query delivers. They are not rivals, and Query is the closest comparison because both are reactive, but the difference is where the truth lives: one is a server-state cache with a fetch lifecycle, the other is a mutable-in-spirit but immutable-in-practice local store you update yourself.

## MIT licensed, pushed daily, released with changesets

The licensing position is the simplest part of the decision. The licence field on the repository says MIT, and a LICENSE file sits at the root, which is a permissive grant that suits both commercial products and internal libraries without a separate negotiation. On maintenance, the last push was on 2026-10-19, so the tree is changing daily, and the release dates cluster in the same window as the versions quoted above. The publishing workflow is changesets, with a `.changeset/` directory in the tree and root scripts for `changeset`, `changeset:version` and `changeset:publish`, meaning each package version comes from an explicit changeset entry rather than a manual edit. Two operational details follow from the tooling. The version script runs a non-frozen install and then a format pass, so versioning rewrites the lockfile and the formatting, and the release process is per-package, which is consistent with adapters shipping independently. For a dependency you intend to keep for years, that per-package independence is a feature and a source of upgrade work at the same time.

## Conclusion

TanStack Store is worth adopting for teams that want one state model shared across React, Solid, Vue, Angular or Svelte components, or that need the same store primitives inside a library they publish, and it is a good fit for anyone already inside the TanStack ecosystem where Query, Form and DB expect a common reactive core. It is the wrong choice if you want batteries included documentation in the repository, if you need a framework's own tooling for debugging, or if a single-framework app is better served by that framework's own state primitives. Verify first that the adapter you need has reached a stable release, since the react and vue packages are still at 1.0.0-alpha.0 while svelte sits at 0.12.3, and check the store API reference on tanstack.com/store before committing, because the repository itself carries only a summary and an ecosystem map.

## FAQ

### How do I install TanStack Store?

The repository README points to the documentation site at tanstack.com/store for setup instructions and does not give an install command itself. The published package names follow the scoped convention used in the release history, including `@tanstack/store` and adapter packages such as `@tanstack/react-store`.

### Which frameworks does TanStack Store support?

The README names React, Solid, Vue, Angular, Svelte, Lit and Octane, and the `examples/` directory holds separate example applications for angular, lit, octane, preact, react, solid, svelte and vue.

### Is TanStack Store a replacement for TanStack Query?

No. The ecosystem list describes Query as async state and caching, while Store is the reactive data store for client state that components read and write directly, including data delivered by Query. They are complementary rather than competing.

### Is TanStack Store stable to depend on?

It is MIT licensed and the last push was on 2026-10-19, but the adapters are not at the same maturity level. `@tanstack/react-store@1.0.0-alpha.0` and `@tanstack/vue-store@1.0.0-alpha.0` were released on 2026-10-10, while `@tanstack/svelte-store@0.12.3` came out on 2026-10-09.

## Sources

- [License: MIT](https://github.com/TanStack/store/blob/main/LICENSE)
- [Project website](https://tanstack.com/store)
- [README](https://github.com/TanStack/store/blob/main/README.md)
- [Releases](https://github.com/TanStack/store/releases)
- [TanStack/store on GitHub](https://github.com/TanStack/store)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tanstack-store