GO — Healthy across the board

• Last commit today
• 27+ active contributors
• Distributed ownership (top contributor 25% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

Redux is a JavaScript library that provides predictable, centralized global state management for applications. It enforces a unidirectional data flow (action → reducer → state) and enables time-travel debugging, making application state changes explicit and testable. The core library is tiny (2kB) and agnostic to view libraries, though commonly paired with React via react-redux. Monorepo structure with core Redux library as the main export, accompanied by extensive documentation under docs/ (API reference, FAQs, design decisions), GitHub issue templates for bug reports and feature requests, and CI workflows. The source is TypeScript-first (165k TS lines vs 20k JS), with a .prettierrc.json and ESLint configuration (.eslintrc.cjs) enforcing code style.

Frontend developers (especially React developers) building medium to large applications who need reliable, debuggable global state management. Contributors range from framework maintainers to application engineers adopting Redux Toolkit, the official recommended approach for new Redux applications.

Highly mature and actively maintained. Redux is a foundational library with millions of weekly npm downloads and a well-established ecosystem. The repo has comprehensive CI/CD pipelines (.github/workflows/test.yaml, publish.yml), extensive documentation in docs/, and TypeScript-first codebase (165k lines). This is production-ready, battle-tested infrastructure.

Very low risk. Redux is one of the oldest and most stable state management libraries in JavaScript with a large, stable community. The single-maintainer concern is mitigated by ReduxJS organization ownership. Primary risk: Redux itself is increasingly positioned as a lower-level primitive, with Redux Toolkit (@reduxjs/toolkit ^2.0.1 in devDeps) now the recommended entry point, so direct Redux adoption is declining in favor of the more ergonomic Toolkit.

The repository actively maintains Redux core while promoting Redux Toolkit as the official recommended approach. Recent activity includes version management via .release-it.json and yarn 4.4.1 (.yarn/releases), test automation (test.yaml workflow), and size tracking (.github/workflows/size.yaml). The focus is stability and backward compatibility rather than new core features.

git clone https://github.com/reduxjs/redux && cd redux && yarn install && yarn test

Daily commands: yarn install && yarn test (see .github/workflows/test.yaml for CI pipeline). For docs: the docs/ directory contains markdown and JSX components (docs/components/DetailedExplanation.jsx) that render to redux.js.org.

• README.md — Entry point explaining Redux's purpose, core features, and the relationship to Redux Toolkit as the recommended approach.
• docs/introduction/CoreConcepts.md — Foundational documentation covering actions, reducers, and the store—essential for understanding Redux architecture.
• docs/tutorials/fundamentals/part-2-concepts-data-flow.md — Core tutorial explaining Redux's unidirectional data flow and state management patterns.
• docs/api/api-reference.md — Complete API reference for all Redux functions; required reading for understanding available APIs.
• .github/workflows/test.yaml — CI/CD pipeline defining test execution and validation requirements for contributions.
• CONTRIBUTING.md — Contribution guidelines and development setup instructions for the Redux repository.
• package.json — Project metadata and dev dependencies (Vitest, React, Redux Toolkit) defining the development environment.

• Store (core) (JavaScript (synchronous dispatch)) — Holds application state, accepts actions, runs reducers, and notifies subscribers of changes.
  • Failure mode: Mutations to state, missed subscriber updates, or lost actions if middleware fails.
• Actions (Plain JavaScript objects) — Serializable objects describing what happened, dispatched to trigger state changes.
  • Failure mode: Non-serializable payloads prevent time-travel debugging; unclear intent without proper type constants.
• Reducers (JavaScript (pure functions, immutability patterns)) — Pure functions computing new state from current state and action, must return new object references.
  • Failure mode: Mutations cause stale subscriber updates and unpredictable behavior; side effects break reproducibility.
• Middleware (JavaScript (function composition)) — Intercepts actions to handle async logic, logging, crash reporting, or store enhancement.
  • Failure mode: Unhandled exceptions in middleware prevent action dispatch; incorrect ordering breaks effect composition.
• React Integration (react-redux) (React hooks, context API) — Connects Redux store to React components via Provider, useSelector, and useDispatch hooks.
  • Failure mode: Incorrect selector memoization causes performance regressions; missed dependencies trigger stale closures.
• Redux DevTools (Browser extension API, dev-only middleware) — Browser extension enabling time-travel debugging, action replay, and state inspection.
  • Failure mode: Non-serializable state prevents snapshots; heavy middleware overhead without proper configuration.

• React Component → Store — Component dispatches action via useDispatch() hook.
• Store (dispatch) → Middleware — Action passes through middleware chain (e.g., thunk, logger, crash reporter).
• Middleware → Reducer — Middleware forwards action to reducer, which computes new state.
• Reducer → Store — Store updates state and notifies all subscribers (React components).
• Store → React Component — Component receives state via useSelector() hook and re-renders if selected slice changed.

Add a new Core Concept Tutorial

1. Create a new markdown file in docs/tutorials/fundamentals/ (docs/tutorials/fundamentals/part-X-new-concept.md)
2. Define the learning objective and add headings for explanation, examples, and exercises (docs/tutorials/fundamentals/part-X-new-concept.md)
3. Reference the new tutorial from the index file (docs/tutorials/tutorials-index.md)

Add a new API Reference Section

1. Create a new markdown file in docs/api/ (docs/api/newFunction.md)
2. Document function signature, parameters, return value, and usage examples (docs/api/newFunction.md)
3. Add entry to the API reference index (docs/api/api-reference.md)

Add a new FAQ Category

1. Create a new markdown file in docs/faq/ (docs/faq/NewCategory.md)
2. Structure content as question-and-answer pairs with code examples (docs/faq/NewCategory.md)
3. Link from FAQ index or related documentation sections (docs/faq/General.md)

• Vitest — Modern, fast test runner with browser simulation support via Playwright for testing Redux behavior.
• React & react-redux — Demonstration of Redux integration with React, the most common use case for state management.
• Redux Toolkit — Officially recommended abstraction layer that simplifies Redux boilerplate and prevents common mistakes.
• Markdown documentation with GitBook — Accessible, version-controlled documentation published to redux.js.org for learners and contributors.

• Minimal core library (2kB) with separate Redux Toolkit package

  • Why: Allows flexibility for advanced users while providing simplified APIs for most developers.
  • Consequence: Users must choose between low-level Redux or higher-level Toolkit; documentation burden to guide the choice.

• Focus on predictable, synchronous state updates with explicit middleware for async logic

  • Why: Enables time-travel debugging and deterministic state management.
  • Consequence: Async operations require middleware setup (thunks, sagas); less convenient than implicit async patterns.

• Comprehensive documentation over API minimalism

  • Why: Educational value and reducing learning curve for new users.
  • Consequence: Large docs footprint (596 files); maintenance burden for keeping examples current.

• Does not provide built-in async data fetching—middleware or Redux Toolkit Query required.
• Does not handle component form state—use local component state or separate form libraries.
• Not a real-time database—no automatic synchronization or subscriptions (handled by middleware).
• Does not mandate a specific project structure—flexibility is intentional, Toolkit provides recommendations.
• Not a replacement for component local state—Redux is for global, shared state only.

• Avg cyclomatic complexity: ~4 — Redux core is simple (synchronous dispatch/reduce), but middleware composition, async patterns, and integration with React add conceptual overhead.
• Largest file: docs/tutorials/fundamentals/part-6-async-logic.md (450 lines)
• Estimated quality issues: ~2 — Documentation is well-maintained with clear examples, but some advanced patterns (middleware chaining, dev tools integration) could benefit from more visual diagrams.

• Mutating state directly in reducers (High) — docs/faq/Reducers.md, docs/tutorials/fundamentals/part-3-state-actions-reducers.md: Modifying reducer input state instead of returning a new object breaks Redux's change detection and time-travel debugging.
• Side effects in reducers (High) — docs/tutorials/fundamentals/part-6-async-logic.md: API calls or I/O operations in reducers break pure function semantics and make state transitions non-deterministic.
• Non-serializable state or actions (Medium) — docs/faq/Reducers.md, docs/understanding/history-and-design/middleware.md: Functions, Promises, or class instances in state prevent time-travel debugging and make snapshots impossible.
• Selector without memoization (Medium) — docs/tutorials/essentials/part-6-performance-normalization.md: Creating new objects in selectors (e.g., array.map() without reselect) causes unnecessary re-renders on every dispatch.
• Global state for everything (Low) — docs/faq/OrganizingState.md, docs/usage/ConfiguringYourStore.md: Storing form state or short-lived UI state in Redux adds boilerplate; component local state is often better.

• docs/tutorials/essentials/part-5-async-logic.md (API/DX friction) — Async middleware setup (thunks vs. sagas) is verbose and error-prone; Redux Toolkit's createAsyncThunk partially addresses this.
• docs/usage/ConfiguringYourStore.md (Configuration complexity) — Store configuration with multiple middleware and enhancers requires careful ordering and understanding of composition.
• docs/faq/Performance.md (Performance tuning complexity) — Selector memoization is critical for performance but requires understanding of reselect or createSelector patterns.

1. Redux core is intentionally minimal — most feature requests should target Redux Toolkit instead (see @reduxjs/toolkit in devDeps). 2. The docs/ folder uses Gitbook integration (.gitbook.yaml) for redux.js.org; changes to markdown must match their schema. 3. Time-travel debugging and DevTools integration are expected behaviors, not optional; tests likely verify these invariants. 4. Yarn 4.4.1 is pinned (.yarn/releases/yarn-4.4.1.cjs); using npm install or older yarn may cause monorepo dependency resolution issues. 5. No explicit monorepo tool (lerna/pnpm) visible — workspace management is via Yarn's native workspaces; check .yarnrc.yml for workspace config.

• Unidirectional Data Flow — The core design principle of Redux — actions flow to reducers which produce new state which flows to views — makes state changes predictable and traceable, essential for debugging and testing in Redux
• Pure Reducers — Redux reducers must be pure functions (same input always produces same output, no side effects) so state changes are deterministic and time-travel debugging works correctly
• Middleware Pattern — Redux middleware intercepts actions before they reach reducers, enabling async operations, logging, and side effects without polluting reducer logic; applyMiddleware.md documents this core extension point
• Immutability — Redux relies on reference equality checks to detect state changes efficiently; mutating state directly breaks this contract and causes silent bugs where components don't re-render
• Selectors — Functions that extract derived state from the store; Redux doesn't mandate selectors but they prevent component coupling to state shape and enable efficient memoization (covered in docs/api/utils.md)
• Time-Travel Debugging — Redux's main ergonomic advantage — the Redux DevTools browser extension replays actions forward and backward to inspect exact state at each step, impossible in mutable state systems
• Store as Single Source of Truth — Redux enforces one centralized store per application (createStore.md documents this); unlike distributed state patterns, debugging is simpler because state lives in one place and changes are logged

• reduxjs/redux-toolkit — The official, recommended wrapper around Redux core that simplifies boilerplate and includes best practices; most new projects should start here instead of Redux directly
• reduxjs/react-redux — Official React bindings for Redux (useSelector, useDispatch hooks); essential companion for React applications using Redux state
• reduxjs/redux-devtools — Browser extension and library that enables time-travel debugging and inspects Redux action history; the debugging UX that made Redux famous
• mobxjs/mobx — Alternative reactive state management library; different philosophy (observable-based vs unidirectional flow) for developers evaluating Redux's approach
• pmndrs/zustand — Modern lightweight state management alternative with hooks-first API; represents newer patterns that address Redux boilerplate concerns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive API documentation for bindActionCreators with TypeScript examples

The file docs/api/bindActionCreators.md exists but likely lacks detailed TypeScript usage examples and edge cases. Redux is heavily used with TypeScript, and bindActionCreators is a commonly misunderstood API. Adding concrete examples showing type inference, dispatch binding patterns, and common pitfalls would reduce support issues.

• [ ] Review current docs/api/bindActionCreators.md content for gaps
• [ ] Add TypeScript type signature examples with explanations
• [ ] Include practical examples: binding action creators in components, middleware, and store setup
• [ ] Document the difference between binding individual creators vs. action creator objects
• [ ] Add a 'Common Pitfalls' section addressing typing issues with async thunks

Create integration test suite for Redux core with React-Redux and RTK in docs/tutorials

The docs folder has devDependencies on react, react-redux, and @reduxjs/toolkit but no visible integration tests demonstrating how these three libraries work together. Contributors often misunderstand the relationship between Redux core, React-Redux bindings, and RTK. Adding an integration test file would clarify expectations and serve as executable documentation.

• [ ] Create docs/tutorials/integration-test.spec.ts or similar using vitest (already configured)
• [ ] Test basic Redux store creation with createStore() and RTK's configureStore()
• [ ] Test React-Redux Provider integration and hooks (useSelector, useDispatch)
• [ ] Test action creator binding patterns with Redux core vs. RTK
• [ ] Ensure tests run in vitest-browser-react environment per package.json config

Add migration guide from createStore to configureStore in docs/introduction

The README and docs/redux-toolkit/overview.md mention RTK is 'Redux today' but there's no dedicated migration guide in docs/introduction. Given that createStore is still in the codebase but RTK's configureStore is recommended, a docs/introduction/MigrateFromCreateStore.md would help developers understand the transition path, what changes, and why.

• [ ] Create docs/introduction/MigrateFromCreateStore.md
• [ ] Compare old createStore patterns with new configureStore equivalents
• [ ] Document middleware setup differences (Redux core applyMiddleware vs. RTK getDefaultMiddleware)
• [ ] Show before/after for common patterns: async thunks, DevTools integration, reducer composition
• [ ] Link this guide from docs/introduction/README.md and docs/redux-toolkit/overview.md

• Expand the docs/faq/ section with a new FAQ entry on 'Immutability and Performance' — the file structure shows docs/faq/ImmutableData.md exists but could benefit from a companion on performance trade-offs with large state trees.
• Add TypeScript type tests or type documentation for the middleware system in docs/api/applyMiddleware.md — the codebase is 165k TS lines but applyMiddleware.md likely lacks TypeScript-specific examples for middleware authors.
• Create a 'Common Mistakes' guide in docs/faq/Miscellaneous.md covering anti-patterns visible in issues, such as mutating state directly or dispatching outside of reducers — low code, high impact.

The Redux repository has a relatively secure posture. As a documentation and library repository, it avoids common backend vulnerabilities like database injection or credential exposure. The main concerns are: (1) outdated testing dependencies that may have known vulnerabilities - recommend running 'npm audit' and updating to latest stable versions, (2) absence of explicit security policy documentation, and (3) need for security headers on the documentation site. The codebase appears well-maintained with proper CI/CD workflows (test.yaml, publish.yml) and dependency management. Regular dependency audits and security policy documentation would further strengthen the security posture.

• Medium · Outdated Testing Dependencies — docs/package.json. The devDependencies include @vitest/browser-playwright@^4.0.5 and vitest@^4.0.5. While not critical, Vitest 4.x is older and may contain known vulnerabilities. The caret (^) versioning allows patches but consider upgrading to the latest stable versions to ensure security patches are applied. Fix: Run 'npm audit' or 'yarn audit' to identify specific vulnerabilities. Update vitest and @vitest/browser-playwright to their latest versions (v2.0.0+). Consider using 'npm outdated' to identify all outdated packages.
• Low · MSW Mock Service Worker Version — docs/package.json. The Mock Service Worker (msw) is pinned to ^2.0.0, which should be acceptable, but MSW is a testing/development tool. Ensure it's only included in devDependencies (which it is), but monitor for security advisories in this package. Fix: Regularly run 'npm audit' to identify any security vulnerabilities in MSW. Keep the package updated to the latest version within the ^2.0.0 range.
• Low · No Security Configuration Files Detected — Repository root. The repository lacks explicit security configuration files such as .npmrc with security settings, security.md for vulnerability reporting, or SECURITY.md file for security policy. While the repository has good CI/CD workflows (test.yaml, publish.yml), explicit security guidelines would improve transparency. Fix: Create a SECURITY.md file in the root directory outlining the security vulnerability reporting process. Consider adding security-related npm configurations in .npmrc file if needed.
• Low · No Content Security Policy in Documentation — docs/ (entire documentation directory). The documentation site (docs folder) contains MDX and JSX files. There's no evidence of CSP headers or security headers configuration in the build setup. The docs site could be vulnerable to XSS if third-party scripts are injected. Fix: Implement Content Security Policy (CSP) headers in the documentation deployment. Review the build configuration and ensure no dangerouslySetInnerHTML is used in docs/components/. Add security headers to the documentation hosting platform.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/reduxjs/redux shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live reduxjs/redux repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/reduxjs/redux.

What it runs against: a local clone of reduxjs/redux — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in reduxjs/redux | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of reduxjs/redux. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/reduxjs/redux.git
#   cd redux
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of reduxjs/redux and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "reduxjs/redux(\\.git)?\\b" \\
  && ok "origin remote is reduxjs/redux" \\
  || miss "origin remote is not reduxjs/redux (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "docs/introduction/CoreConcepts.md" \\
  && ok "docs/introduction/CoreConcepts.md" \\
  || miss "missing critical file: docs/introduction/CoreConcepts.md"
test -f "docs/tutorials/fundamentals/part-2-concepts-data-flow.md" \\
  && ok "docs/tutorials/fundamentals/part-2-concepts-data-flow.md" \\
  || miss "missing critical file: docs/tutorials/fundamentals/part-2-concepts-data-flow.md"
test -f "docs/api/api-reference.md" \\
  && ok "docs/api/api-reference.md" \\
  || miss "missing critical file: docs/api/api-reference.md"
test -f ".github/workflows/test.yaml" \\
  && ok ".github/workflows/test.yaml" \\
  || miss "missing critical file: .github/workflows/test.yaml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/reduxjs/redux"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.