Redux DevTools: an extension, a standalone app and a React component in one monorepo

Three ways to get it, and no install command for any of them

The delivery mechanisms are named but their commands are not. The browser extension is linked from the Chrome Web Store, the Edge add-ons site and the Firefox add-ons site. A standalone app lives in packages/redux-devtools-app. A React component lives in packages/redux-devtools and is integrated into the client app. The README links a Browser Extension Installation and Configuration page under extension/, but the one install command that appears in the README itself is a contributor command:

pnpm install

Consequence for a user who searched how to install redux devtools: there is nothing here to copy. You pick a browser and click through a store page, or you decide that your code does not live in a browser tab and read about the standalone app instead. The React component route is the one with real integration cost, since it puts developer tooling inside the application you ship, and the README does not discuss how to keep it out of a production bundle.

The npm package name changed shape twice

The release history shows two different names in use: [email protected] in April 2025, @redux-devtools/[email protected] under an organization scope in March 2026, and [email protected] in October 2026. The README's build example uses a third spelling, remotedev-redux-devtools-extension, as a workspace filter name. That is not a cosmetic difference: these are different strings to type, and the unscoped plural name is still being released after the scoped 4.0.0. Consequence for anyone following older material: a lockfile or tutorial may name a different package than the one you expect, and the names differ by a single letter or a scope. If you are upgrading a project that already depends on the old name, the dependency name is the first thing to check before anything else about the 4.0.0 release.

A browser extension, a desktop app and an in-app component are different bets

The framing sentence is broader than Redux: developer tools to power up a Redux development workflow, or any other architecture which handles the state change, with an integrations document behind that claim. Given that, the three forms cost different amounts. The standalone app exists for the case where the state lives outside a browser tab. The React component is embedded, so it shares the app's lifecycle and its build. Consequence for a team: the same tool produces different debugging ergonomics depending on the form. Note also that the README's own link for the React component points at the master branch while the repository default branch is main, which is the kind of detail that sends a reader to a stale tree.

The monorepo has a build order and a pinned package manager

Development runs on pnpm, and the root package.json pins the version with packageManager set to [email protected]. Installation is the install command above, and the first rule stated is that each package's dependencies need to be built before the package itself can be built. That means you can build everything at once:

pnpm run build:all

or scope the work to one package and its dependency graph:

pnpm --filter "remotedev-redux-devtools-extension" build

Consequence for a new contributor: cloning and jumping straight into a single package does not work, because its dependencies are unbuilt. The filter form is the way around it, but only if you pass the same package name the workspace uses. Note that the example filter names remotedev-redux-devtools-extension, a spelling that matches neither release name.

Formatting and linting run on oxlint, not the usual suspects

The root scripts are short enough to read in one go: format is oxfmt, format:check is oxfmt --check, lint is oxlint, lint:fix is oxlint --fix, clean:all recurses, and test is vitest --run. The dev dependencies match, with oxfmt, oxlint and oxlint-tsgolint as the tooling, and the configuration lives in .oxfmtrc.json and .oxlintrc.json at the root. Testing uses vitest with jsdom pulled from the workspace catalog, and there is an arethetypeswrong CLI in dev dependencies, which is a type definition checker, alongside a typescript compiler version that also comes from the catalog. Consequence for a contributor arriving from a typical JavaScript repo: your editor defaults and your muscle memory will both be wrong here, since there is no eslint config or prettier config to pick up automatically, and the type-aware linting step is part of the toolchain rather than something a maintainer runs by hand.

Version bumps and publishing are two different paths

The release script is one line: pnpm build:all && pnpm publish -r. Alongside it sit a .changeset directory, the changesets CLI in dev dependencies, renovate.json for dependency updates, and a patches directory for patched packages. Consequence for anyone shipping a fix: the publish command pushes whatever versions the packages already carry, and a changeset workflow implies a version decision somewhere else, so the two mechanisms do not obviously compose from the manifest alone. If your change needs a release, that is a question for maintainers rather than something the scripts answer. The same split shows up in dependencies, where several dev dependencies are declared as catalog: references, meaning their real versions are centralized in pnpm-workspace.yaml instead of being visible in package.json.

The option surface lives under extension/docs, not in the README

The README is a link hub. Configuration for the browser extension is extension/docs/API/Arguments.md, advanced methods are extension/docs/API/Methods.md, manual integration as a React component is docs/Walkthrough.md, remote monitoring is docs/Integrations/Remote.md, and there are separate pages for troubleshooting, recipes and an FAQ under the extension docs tree. Consequence for a reader who expects the README to answer a question: it will not. Whether a given knob exists, what it defaults to, and whether it applies to the extension or the component form all require opening another file. The same applies to state libraries other than Redux, which are handled by the integrations document rather than by anything in the top-level file.

The repository homepage points at a video

The homepage recorded for this project is a YouTube link, not a documentation site, and the top of the README leads with pull requests, backers and sponsors before it reaches any explanation of the tool. Funding runs through OpenCollective, with separate backer and sponsor pages under the redux-devtools-extension slug. Consequence for anyone arriving from package metadata or a directory listing: the first pointer they get is a talk recording, and the two funding links take up more of the visible page than the tool's own scope. For an evaluation, that means the useful signal is in the docs tree and the extension packages, and the front page of the repository is not where a scoping decision gets made.

Editorial conclusion

This repository is the right place for anyone who wants to watch state transitions rather than just the final state, and it fits Redux as well as any other architecture that handles state changes. Pick the delivery form by where the code runs: the browser extension for a web app, the standalone app when the code is not in a browser tab, and the React component only if you are disciplined about keeping dev tooling out of production bundles. Before you rely on any snippet you find online, check three things. The package name, because releases ship as remotedev-redux-devtools-extensions and @redux-devtools/extension, while the README's build example filters on remotedev-redux-devtools-extension, so a lockfile or tutorial may name a different package than you expect. The branch your instructions assume, since the default is main while one README link still points at master. And the documentation location, because the option and method references live under extension/docs rather than in the README itself.

Frequently asked questions

Official sources

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