React Redux ships four entry points, and one of them is for React Server Components

One package name, four files, decided by the condition your bundler sets

The published surface is described by the exports map in package.json rather than by a single entry.

    ".": {
      "types": "./dist/react-redux.d.ts",
      "react-server": "./dist/rsc.mjs",
      "react-native": "./dist/react-redux.legacy-esm.js",
      "import": "./dist/react-redux.mjs",
      "default": "./dist/cjs/index.js"
    },

Types resolve first, then a React Server condition pointing at rsc.mjs, then react-native, then a modern ESM build, and a CommonJS fallback last. Two details are worth pausing on. The React Native consumer is served the file named legacy-esm, which is also the package's module field, so React Native deliberately gets the older build. And a resolver that ignores conditions entirely falls through to dist/cjs/index.js without complaining.

There is a second subpath, ./alternate-renderers, mapping types and the ESM build with the same CommonJS default. That is the escape hatch for renderers outside React DOM.

package.json says 9.3.0, and the three newest tags are 9.4.0 alphas

Look at the version field and you read 9.3.1. Look at the release list and the most recent entry is v9.3.1 on 2026-10-27, preceded by v9.4.0-alpha.2 on 2026-09-29 and v9.4.0-alpha.1 on 2026-09-24.

So the manifest tracks the 9.3 line while 9.4.0 alphas sit in the tag list, and two alphas five days apart is a fast prerelease cadence. A reader who copies an alpha tag name into a package.json pins an alpha, while a reader who installs with npm gets whatever the latest tag points at. Those are not the same thing, and the README does not warn about the difference.

Two other facts from the same file decide how the package behaves rather than which version it is. sideEffects is false, which lets a bundler drop unused modules, and files contains only dist and src, so the raw TypeScript sources ship alongside the compiled output.

react, redux and @types/react are peers, so nothing here installs a store

The dependency section is short and entirely peer-scoped.

  "peerDependencies": {
    "@types/react": "^18.2.25 || ^19",
    "react": "^18.0 || ^19",
    "redux": "^5.0.0"
  },

Three consequences follow. React 17 is out, since the README puts the floor higher with a sentence of its own: React Redux 9.0 requires React 18 or later. Redux 4 is out, because the peer range starts at ^5.0.0. And peer dependencies are not installed for you, so the README adds that you also need to install Redux and set up a Redux store in your app, linking its recipe page for exactly that.

That is the whole shape of this package. It binds a store you provide to components you write. It contains no store, no reducer creator and no middleware, which is why an application cannot adopt it as its state layer on its own.

The documented starting point is a template, not an install command

The README offers two routes for a new application and one for an existing one. For something greenfield it points at the official Redux and TypeScript template for Vite, or at the with-redux example when you are starting a Next.js project.

# Vite with our Redux+TS template
# (using the `tiged` tool to clone and extract the template)
npx tiged reduxjs/redux-templates/packages/vite-template-redux my-app

# Next.js using the `with-redux` template
npx create-next-app --example with-redux my-app

Both arrive with Redux Toolkit and React-Redux configured for that build tool and a small example app showing several Redux Toolkit features, which is the difference between the two routes and a plain install. For an app that already exists, the step is shorter.

# If you use npm:
npm install react-redux

# Or if you use Yarn:
yarn add react-redux

That command installs the binding and nothing else. The store, the reducers and the choice of how to write them all remain your problem, which is the decision this package is leaving to you.

The cdnjs UMD build exists, and the README tells you not to use it

There is a single-file UMD build available from cdnjs that makes ReactRedux a global object for a script tag. The README does not leave the judgement implicit. It says not to recommend that approach for any serious application, and gives the reason: most of the libraries complementary to Redux are only available on npm.

That is a real constraint rather than a preference. A script-tag setup cannot pull in the packages that surround a Redux application, so anything you build on top of it has to be loaded the same way or not at all. Fine for a demonstration on a single page, wrong for anything with dependencies.

The other assumption in the same paragraph is that you consume CommonJS modules through a bundler such as Webpack or Browserify. The UMD build is the documented fallback for people who do not, and the npm path is the documented answer for people who do.

The two links that explain how it works were published in 2018 and 2019

There is a How Does It Work section on the front page, and it contains two blog links rather than an explanation. The first is The History and Implementation of React-Redux, published in November 2018, which covers what the library does, how it works, and how the API and implementation have evolved. The second is a Deep Dive into React-Redux talk from June 2019 covering some of the same ground at a higher level.

So the authoritative explanation of the implementation on the front page of a 9.x package was written before the package reached 9. That does not make the posts wrong, and the README points at the docs at react-redux.js.org as the place for the current API. It does mean that a reader who wants to understand the binding's behaviour has to reconcile a 2018 write-up with the exports map above.

Note also what the README does not contain. It has no Provider example, no hook example, and no mention of useSelector or useDispatch. For a package whose entire job is connecting components to a store, the front page defers all of that to the documentation site.

vitest runs with typecheck on, and prepack runs the build

The scripts section describes a pnpm workspace, which pnpm-lock.yaml and pnpm-workspace.yaml confirm, with oxlint and oxfmt for linting and formatting, tsdown for bundling, and vitest for tests.

    "test": "vitest --run --typecheck",
    "test:watch": "vitest --watch",
    "type-tests": "tsc --noEmit -p tsconfig.test.json"

Running tests type-checks them in the same command, and a separate type-tests target runs tsc against tsconfig.test.json. The build script cleans first, runs tsdown, then runs scripts/stripSourcemapFileField.mts, which, as its name says, strips the file field from the generated sourcemaps. prepack runs the build, so the artefact you install is produced during publish rather than committed.

Release automation is configured separately in .release-it.json, which is consistent with the alpha cadence in the tag list. The docs site has its own netlify.toml and CNAME, so the website lives in this repository alongside the code.

Redux Toolkit is the part that carries your reducers, not this one

The alternative that shows up most often in questions about this package is Redux Toolkit, and the README itself points at it. Both starter templates arrive with Redux Toolkit and React-Redux already configured.

The difference in approach is not a preference between two similar libraries. React Redux is a binding: given a store it subscribes components and hands them state and actions. Redux Toolkit is where the store, the slice reducers and the middleware come from, and it is a separate package. Install React Redux alone and you still have to choose a way to define reducers and to create the store yourself.

What neither package does is persist state, talk to a server, or handle routing, so an application built on both still owns those layers. The README makes no performance claim against any alternative, and the repository gives you no benchmark to compare one with, so the choice here has to be made on the shape of the API rather than on numbers.

Editorial conclusion

React Redux fits a React 18 or 19 application already running Redux 5 that has its own store and reducers, and that can rely on conditional exports to pick the right build. It does not fit an app hoping to get a state layer from one package, because there is no store, no reducer helper and no middleware here, and neither React 17 nor Redux 4 satisfies the peer range. Verify first which artefact you actually installed, since package.json reads 9.3.1 while 9.4.0 alpha tags also sit in the release list, and the tag npm resolves matters more than the tag you read on the releases page.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. reduxjs/react-redux on GitHub
5. Releases