@next/third-parties fails with Next 15 and React 19 RC because its peerDependencies range is too restrictive, so package managers reject an otherwise compatible install before your app even runs.

This issue typically appears when upgrading a project to Next.js 15 or React 19 RC on the canary channel and then adding or reinstalling @next/third-parties. The package declares a peer dependency range that does not include these newer versions, so npm, pnpm, or Yarn reports a dependency resolution error.

If you want to inspect the original reproduction, see the CodeSandbox reproduction.

Understanding the Root Cause

This is not primarily a runtime bug in your application code. It is a package metadata compatibility problem.

The @next/third-parties package uses peerDependencies to declare which versions of next, react, and sometimes react-dom it officially supports. When you install dependencies, your package manager validates those ranges. If your app uses next@15 or react@19.0.0-rc, but the package only allows older versions such as Next 14 or React 18, installation fails with an ERESOLVE or peer dependency conflict.

Why this happens technically:

• Peer dependency ranges are strict contract metadata. Even if the code would work, the package manager only sees the declared semver range.
• Release candidates like React 19 RC often do not satisfy stable ranges such as ^18.
• Canary or pre-release Next.js versions frequently move faster than satellite packages, creating temporary metadata mismatches.
• @next/third-parties is tightly related to the Next.js ecosystem, so a lag in published peer ranges can block upgrades.

In short, the install fails because the package manifest says, effectively, I do not support your framework version, even when the implementation may already be compatible.

Step-by-Step Solution

The cleanest fix is to align on a version of @next/third-parties that explicitly supports Next 15 and React 19 RC. If that version is not yet published, use one of the temporary workarounds below.

1. Confirm the exact dependency conflict

Run your install command and inspect which peer range is failing.

npm install

pnpm install

yarn install

Typical error patterns include messages like these:

npm ERR! Could not resolve dependency:
npm ERR! peer react@"^18.2.0" from @next/third-parties@x.x.x
npm ERR! peer next@"^14.0.0" from @next/third-parties@x.x.x

2. Check whether a newer compatible package version exists

Before applying a workaround, verify whether a newer release or canary version already expands the peer dependency range.

npm view @next/third-parties versions --json

npm view @next/third-parties peerDependencies --json

If a compatible version exists, install it directly:

npm install @next/third-parties@latest

Or, if support has landed only in a canary build:

npm install @next/third-parties@canary

3. Use a package manager override as a temporary workaround

If the package code works but the peer metadata is outdated, the safest temporary approach is to keep your app versions and tell your package manager how to resolve the dependency tree.

For npm, you can install with legacy peer handling as a short-term unblocker:

npm install --legacy-peer-deps

Or force the install if you understand the risk:

npm install --force

For pnpm, add an override in package.json if needed for transitive alignment:

"pnpm": {
  "overrides": {
    "react": "19.0.0-rc-...",
    "react-dom": "19.0.0-rc-...",
    "next": "15.0.0-canary.0"
  }
}

For Yarn, use resolutions:

{
  "resolutions": {
    "react": "19.0.0-rc-...",
    "react-dom": "19.0.0-rc-...",
    "next": "15.0.0-canary.0"
  }
}

These approaches do not change the peer dependency declaration itself, but they can help stabilize the installed graph while you verify runtime behavior.

4. Patch the package metadata locally when install validation is the only blocker

If you have confirmed that the package works at runtime, use patch-package to widen the peer dependency range locally until the upstream package is fixed.

npm install -D patch-package postinstall-postinstall

Add a postinstall script:

{
  "scripts": {
    "postinstall": "patch-package"
  }
}

Install dependencies with legacy peer handling once if required, then edit the installed package manifest under node_modules/@next/third-parties/package.json so its peer dependencies include your versions:

{
  "peerDependencies": {
    "next": "^14.0.0 || ^15.0.0-0",
    "react": "^18.2.0 || ^19.0.0-0",
    "react-dom": "^18.2.0 || ^19.0.0-0"
  }
}

Then create the patch:

npx patch-package @next/third-parties

This is often the most controlled workaround in teams because the fix is versioned in your repository.

5. Validate runtime compatibility

After installation succeeds, verify that the package actually behaves correctly with your stack.

npm run dev

npm run build

Then test the exact integration points where @next/third-parties is used, such as Google integrations, script injection, or analytics-related components.

6. Prefer the upstream fix once released

The long-term resolution is for the maintainers to publish a package version with updated peerDependencies. Once available, remove any temporary patch, override, or forced install flag and return to a standard install flow.

npm uninstall patch-package postinstall-postinstall

Then delete the generated patch file and reinstall cleanly:

rm -rf node_modules package-lock.json
npm install

Common Edge Cases

• React and react-dom version mismatch: If react is on 19 RC but react-dom is still on 18, you may see additional peer or runtime errors.
• Lockfile drift: A stale package-lock.json, pnpm-lock.yaml, or yarn.lock can preserve an older broken resolution. Regenerating the lockfile often helps.
• Monorepo hoisting issues: In workspaces, one package may pull React 18 while another uses React 19 RC, creating confusing duplicate dependency trees.
• Canary instability: Even after bypassing peer validation, a canary build of Next.js may expose unrelated runtime regressions that look like package compatibility bugs.
• CI vs local mismatch: Your local machine may install with a permissive flag, while CI uses a strict install command and fails. Make sure your workaround is reproducible in automation.
• Strict package managers: pnpm often surfaces peer issues more explicitly than npm, so a setup that appears fine locally with npm may still fail in another environment.

FAQ

Can I safely use –legacy-peer-deps for production?

It is acceptable as a temporary unblocker, but it is not the best long-term solution. It suppresses peer validation globally and can hide real incompatibilities. A targeted patch or an upgraded package version is safer.

Why does this happen with React 19 RC even if the library code seems compatible?

Because release candidate versions usually fall outside stable semver ranges. Package managers evaluate declared version ranges, not just runtime behavior.

Should I downgrade Next 15 or React 19 RC to fix this?

Only if you need maximum stability immediately. If your project depends on canary or RC features, a local patch or temporary override is usually a better short-term strategy until @next/third-parties publishes updated peer metadata.

The practical takeaway is simple: this bug is caused by outdated peer dependency declarations, not necessarily broken application logic. Update to a compatible release if one exists, otherwise use a controlled workaround such as patch-package and remove it once the upstream fix lands.