Redux in React: how the 2kB core, Redux Toolkit and the templates fit

The core is 2kB and the last release is still 5.0.1

Size is the headline number, and it is a small one: the core is 2kB including dependencies, with a rich ecosystem of addons around it. What the repository adds is a different kind of fact. package.json still reads version 5.0.1, and the published releases stop at v5.0.1 on 2023-12-23, with v5.0.0 on 2023-12-04 and v5.0.0-rc.1 on 2023-11-23 before it. Commits have not stopped: the last push was on 2026-09-29 and the project is not archived. So the maintenance story is tooling and internals, not new versions on the registry, and a team pinning versions should notice that the code landing on master is newer than anything installable from npm.

Three official templates, and the two packages underneath them

Starting points come from templates rather than from a bare install, because the templates arrive with Redux Toolkit and React-Redux already configured for the build tool in question, plus a small example app showing several Redux Toolkit features. For a Vite React app or a Next.js app:

# 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

React Native has its own Expo template, npx tiged reduxjs/redux-templates/packages/expo-template-redux-typescript my-app. If you are wiring Redux into an existing project, the packages are the whole install:

npm install @reduxjs/toolkit react-redux

The core library alone is a separate command, npm install redux, and the README labels Redux Toolkit the official recommended approach for writing Redux logic, on the grounds that it builds in the suggested best practices and prevents common mistakes.

createSlice lets you write mutating code over an Immer draft

The core model has three moving parts. The whole global state of an app sits in an object tree inside a single store, the only way to change that tree is to create an action describing what happened and dispatch it to the store, and pure reducer functions calculate a new state from the old state and the action. Redux Toolkit sits on top and lets you write reducers that look like they mutate:

const counterSlice = createSlice({
  name: 'counter',
  initialState: {
    value: 0
  },
  reducers: {
    incremented: state => {
      state.value += 1
    },
    decremented: state => {
      state.value -= 1
    }
  }
})

Nothing is mutated in place. The Immer library detects changes to a draft state and produces a brand new immutable state from them, so a reducer body that assigns to state still returns a new tree. A reader who skips that detail will misread the code as in place mutation, which is the misunderstanding that later breaks time travel and any memoised selector.

Time travel works because the tree is one object

The developer experience the README advertises is live code editing combined with a time traveling debugger, and the mechanism behind it is the shape of the data: one store, one object tree, changes only through dispatched actions, reducers pure enough to replay. The keyword list in package.json says the same thing in a few words, with hot, live and replay listed alongside redux, reducer, state, predictable, functional and immutable. The practical consequence is that every piece of state has to survive being serialised and reconstructed, so putting a file handle, a DOM node or a class instance in the store undercuts the feature the library is known for. The README does not document a serializability check or a warning for this case, so nothing will stop you except knowing the constraint.

Two tutorials, one top down and one bottom up

The documentation splits on purpose, and picking the wrong one wastes a day. Redux Essentials is a top-down tutorial that teaches how to use Redux the right way, using the latest recommended APIs and best practices, and the README recommends starting there. Redux Fundamentals is bottom-up: it teaches how Redux works from first principles and without abstractions, and why the standard Redux usage patterns exist. Core documentation lives at redux.js.org with Introduction, Tutorials, Usage Guides, FAQ and an API Reference, while Redux Toolkit has its own site at redux-toolkit.js.org with references for all of its APIs. The docs directory and the website directory in the repository hold those sources, so the split is visible in the tree as well as in the links. Help runs through the #redux channel on the Reactiflux Discord, not through the issue tracker.

The README admits its own criteria for using Redux are vague

Before proceeding further, the README asks you to consider whether Redux is appropriate for your situation, and to avoid using it just because someone said you should. It then offers three suggestions for when it makes sense: you have reasonable amounts of data changing over time, you need a single source of truth for your state, and you find that keeping all your state in a top-level component is no longer sufficient. It calls those guidelines subjective and vague on purpose, because the point at which you should integrate Redux into an application is different for every user and every application. For a team, that is a real gap: there is no threshold to measure, and the answer has to come from your own state shape. The README points at When (and when not) to reach for Redux, You Might Not Need Redux and both parts of The Tao of Redux rather than settling the question itself.

The publish path runs format, lint and tests before build

The scripts in package.json show what contributing to this project costs, and they are unusually legible. Formatting runs through oxfmt over {src,test}/**/*.{js,ts} and docs/**/*.md, linting through oxlint src test, and tests through vitest with the typecheck flag; type-tests call tsc against tsconfig.test.json. The build is pnpm clean, then tsdown, then a script that strips the sourcemap file field, and prepublishOnly runs clean, format:check, lint and test before anything ships, with prepack building the package. The tree matches that workflow: pnpm-workspace.yaml and pnpm-lock.yaml for the package manager, vitest.config.mts and tsdown.config.mts for tooling, .release-it.json for releases, netlify.toml and website for the docs site. The files array publishes only dist and src, so consumers get the TypeScript source alongside the bundle.

Two ESM paths in the exports map, and blame that was rewritten

The package entry is where bundler differences bite. main points at dist/cjs/redux.cjs, module points at dist/redux.legacy-esm.js, types at dist/redux.d.mts, and the exports map serves types, import from dist/redux.mjs and a default of dist/cjs/redux.cjs. A bundler that honours the legacy module field therefore gets a different file from one that follows exports, which is presumably why @arethetypeswrong/cli sits in devDependencies. Below the packaging layer, .git-blame-ignore-revs exists, which means whole history has been reformatted at some point: blame on older commits is rewritten and a line you are about to edit may not look like the line you blame shows. The examples directory, with counter, counter-ts, counter-vanilla, shopping-cart, todos and tree-view, is the fastest way to see which import style each setup expects.

Editorial conclusion

Adopt Redux when state genuinely changes over time and you want one source of truth, and take the templates plus Redux Toolkit rather than the bare core, since the README calls the core alone the less recommended path. Skip it when a top level component still holds your state, because the README's own three criteria cannot tell you when you have crossed the line. Before you start, check which version you actually install, since the newest release is v5.0.1 from 2023-12-23 even though commits landed on 2026-09-29.

Frequently asked questions

Official sources

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