Fix npm Conflicting peer dependency: react@16.14.0

TL;DR#

In the reported React 17 project, redux-form 8.3.7 required React 16 through its peer declaration. The conflicting React 16.14.0 line describes an alternative candidate; the earlier Found line names the React version already selected. Inspect the dependency making the incompatible request. For that exact older dependency combination, changing redux-form to 8.3.10 admitted React 17 without changing React or bypassing peer checks.

The Stack Overflow report contains both Found: react@17.0.2 and Conflicting peer dependency: react@16.14.0. Between them, npm identifies the decisive requirement: peer react@"^16.4.2" from redux-form@8.3.7.

The same range conflict was reproduced on 13 October 2026 with Node 24.21.0 and npm 11.19.0 in an isolated Docker container. Current npm used different diagnostic wording, so this is its actual output rather than a reconstructed historical log:

npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree

It then identifies the package refusing the installed version:

npm error peer react@"^16.4.2" from redux-form@8.3.7

Why it happens#

A peer dependency describes compatibility with another package in the consuming application. npm's peerDependencies reference explains that relationship and the automatic peer installation used by npm 7 and later. Automatic installation does not make incompatible requirements agree.

The published redux-form 8.3.7 manifest requests React with the range ^16.4.2. React 17.0.2 is outside that major-version range. The source's Material UI dependency, by contrast, declares a range admitting React 17 in the printed diagnostic. Its presence in the report does not make it the package responsible for this particular rejected peer.

Read the dependency names together with their ranges. Installing another copy of the version printed after Conflicting peer dependency is not automatically a repair: it can create a new disagreement with React DOM and the rest of the application. The useful question is whether the application's selected React version satisfies every relevant peer declaration.

This also differs from an old npm warning that a peer is absent. The missing peer dependency explanation covers npm versions that leave installation to the application. Here React is present; a dependency rejects its version. Adding the same version again cannot change that declaration.

Check your own peer conflict#

Paste the conflicting-dependency portion of your npm output to compare the selected package with the rejected peer range. The tool runs in your browser; nothing is sent.

Fix#

1. Identify the installed dependency and its requested range#

Run these commands in the application directory containing the failing package.json:

npm pkg get dependencies devDependencies
npm ls react react-dom redux-form react-redux redux

The listing can exit unsuccessfully on a broken tree. Keep its invalid-peer information and compare the installed package versions with the original failure. A workspace or nested client directory can have a different manifest from the repository root.

Inspect the exact package version npm names, rather than assuming today's latest release has the same contract:

npm view redux-form@8.3.7 peerDependencies --json
npm view redux-form@8.3.10 peerDependencies --json

The 8.3.10 registry record declares React ^16.4.2 || ^17.0.0 || ^18.0.0. Its React Redux range also differs from the older record. Check the whole peer set against your application before choosing the update. A range permitting React 18 does not, by itself, permit React 19.

2. Update the package rejecting React, when its newer contract fits#

For the tested application using React 17.0.2, React DOM 17.0.2, Redux 4.1.2 and React Redux 7.2.6, the focused update is:

npm install --save-exact redux-form@8.3.10

This is an example for that existing dependency combination, not a modern React application baseline. Keep an application already using newer React on its intended version; find a dependency that supports it or migrate away from the incompatible library. Do not downgrade the entire application merely to reproduce an old answer.

The controlled fixture began without a lock file or installed packages and reproduced the error with redux-form pinned to 8.3.7. Only that manifest entry was changed to 8.3.10. The same installation then succeeded, and npm's tree listing accepted the unchanged React, React DOM, Redux and React Redux versions. This establishes dependency resolution, not the runtime correctness of a form component or the safety of an application migration.

3. Preserve and verify the resolved installation#

Review the manifest and lock changes together. npm's install documentation describes the relationship between the requested ranges and saved lock resolution. Do not hand-edit a dependency's peer range inside node_modules: that changes a local declaration while leaving the next clean installation dependent on the published package.

After the update, verify the saved dependency tree:

npm ls react react-dom redux-form react-redux redux
npm ci

The npm ci reference documents that a clean install uses the lock and refuses a mismatch with the manifest. It removes an existing node_modules installation before installing, so run it where replacing installed dependencies is appropriate. The reproduction's clean install passed with the repaired manifest and lock.

Run your existing application tests and build afterwards. The experiment disabled lifecycle scripts and audit requests in both the failing and repaired installs to isolate peer resolution. A green dependency check cannot prove that an unrelated native build, bundler or application feature works.

Verify the fix#

The meaningful result is an installation and dependency listing completed with ordinary peer checking. In the reproduction, React stayed at 17.0.2 and redux-form resolved to 8.3.10. No peer bypass or React downgrade was required.

There is an important date distinction in the source. Its root requirement is ^8.3.6, rather than an exact pin to 8.3.7. A fresh installation of that original range in the controlled fixture now selects 8.3.10 and succeeds. Therefore an old report does not establish that every current installation of the same caret range still fails. Inspect the actual selected version, existing lock and other requirements before changing an already compatible project.

If the installed redux-form already declares a range admitting your React version, read the new package named in the failure. Another dependency can impose a different bound. Likewise, a Firebase prerelease peer conflict requires checking prerelease admission, even when a numeric minimum looks permissive. That is a different range mechanism from the stable major-version mismatch reproduced here.

Why the bypass is not the compatibility test#

A separate negative control installed the original incompatible fixture with legacy-peer-deps. Installation completed, but npm ls exited unsuccessfully and labelled React invalid against redux-form's ^16.4.2 requirement. npm's configuration reference documents that the option ignores peer dependencies. The successful bypass therefore cannot verify the focused repair.

The source's accepted answer concerns a subsequent node-sass failure after force was used, rather than proving that the original React peer declaration was compatible. Keep those stages separate. If the next failure names a missing native binding, continue with the Node Sass environment diagnosis. Changing the package that rejects React repairs the dependency contract; a later native compiler or binding error needs its own cause and evidence.

Avoid turning the report's sequence into a universal instruction to force installation and then apply another force-based repair. Read the selected React version, inspect the published peer declaration, choose a compatible dependency, and verify the resulting lock under the same checking mode that the build server uses.

Further reading: Material UI install fails on React 18 or 19 (ERESOLVE): fix.