How to Fix: Cannot install @next/third-parties in Next.js 15
@next/third-parties fails to install in a fresh Next.js 15 app because its published peer dependency range does not yet accept Next 15, even though you are installing the latest versions of both packages. The result is an npm dependency resolution error that looks like a broken install, but the real problem is a version compatibility mismatch between the package metadata and your framework version.
Table of Contents
Understanding the Root Cause
This issue happens during package installation, not at runtime. In a new project created with create-next-app, installing next@latest may pull in Next.js 15. However, the currently published version of @next/third-parties may still declare a peerDependencies range that supports only older Next.js versions, such as 13 or 14.
Package managers like npm enforce peer dependency compatibility during resolution. If @next/third-parties says it requires a different major version of next, npm treats that as a conflict and stops the install. That is why this command fails:
npm install @next/third-parties@latest next@latest
Technically, nothing is wrong with your app scaffold. The failure is caused by version skew between:
- next@latest, which resolves to Next.js 15
- @next/third-parties@latest, which may not yet list Next.js 15 as supported
This is common when an ecosystem package is maintained separately from the main framework release cycle. Until the package is republished with updated peer dependency metadata, npm will continue to reject the combination.
Step-by-Step Solution
The safest fix is to install a compatible pair of versions. You have three practical options depending on your goal.
Option 1: Stay on Next.js 15 and remove @next/third-parties for now
If you need Next.js 15 immediately, avoid installing @next/third-parties until a compatible release is published.
npx create-next-app@latest my-app
cd my-app
npm install next@latest
Then integrate third-party scripts manually using built-in Next.js features such as next/script.
import Script from 'next/script'
export default function Page() {
return (
<>
<Script
src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"
strategy="afterInteractive"
/>
<Script id="google-analytics" strategy="afterInteractive">
{`
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX');
`}
</Script>
</>
)
}
This is the best short-term choice if you do not want dependency hacks.
Option 2: Downgrade Next.js to a version supported by @next/third-parties
If you specifically need @next/third-parties, install a version of next that matches its declared peer range.
npx create-next-app@latest my-app
cd my-app
npm install next@14 @next/third-parties@latest
After that, verify the installed dependency tree:
npm ls next @next/third-parties
If the install completes without peer dependency errors, your versions are aligned.
Option 3: Force installation temporarily for testing only
If you are validating compatibility in a local reproduction and understand the risks, you can bypass npm’s peer dependency enforcement.
npm install @next/third-parties@latest next@latest --legacy-peer-deps
Or:
npm install @next/third-parties@latest next@latest --force
Important: this is not the recommended production fix. It only tells npm to ignore the metadata conflict. The package may still have runtime incompatibilities with Next.js 15.
How to check which version is blocking the install
Run:
npm view @next/third-parties peerDependencies
npm view @next/third-parties version
npm view next version
This will show whether the published peer dependency range includes Next 15. If it does not, the install error is expected.
Recommended final fix
For most teams, the cleanest resolution is:
- Use Next.js 14 with @next/third-parties if you need that package today.
- Or stay on Next.js 15 and replace @next/third-parties with manual next/script integration until an updated release lands.
You can also monitor package updates on the npm package page and check framework compatibility notes in the Next.js documentation.
Common Edge Cases
1. Lockfile or node_modules cache keeps old dependency decisions
If you previously attempted multiple installs, your package-lock.json or node_modules directory may preserve a broken resolution state.
rm -rf node_modules package-lock.json
npm install
Then retry with the exact versions you want.
2. Different package managers behave differently
npm, pnpm, and Yarn do not always handle peer conflicts the same way. A project that installs with one package manager may fail in another. Make sure the reproduction matches the package manager used in your real app.
3. Using canary or experimental Next.js releases
If your project uses canary builds, ecosystem packages often lag behind. In that case, expect strict peer dependency failures unless the third-party package explicitly supports that release line.
4. CI passes locally but fails in automation
A local install using –legacy-peer-deps may appear fine, while CI using a clean environment fails because it runs a strict install. Ensure your CI and local dependency strategy are consistent.
5. The package installs with force, but imports fail later
Even if npm allows the package through, type errors, build errors, or unsupported APIs can still appear if @next/third-parties has not actually been validated against Next.js 15.
FAQ
Why does @next/third-parties@latest not work with next@latest?
Because latest on two packages does not guarantee they are mutually compatible. @next/third-parties can publish a latest version whose peerDependencies still exclude Next.js 15.
Can I safely use –legacy-peer-deps in production?
Usually no. It bypasses dependency validation rather than fixing compatibility. Use it only for short-lived testing unless you have confirmed the package works correctly with your exact Next.js version.
What is the best replacement for @next/third-parties on Next.js 15?
Use built-in next/script and standard app integration patterns until official support is published. That keeps your app aligned with Next.js 15 without relying on unsupported peer dependency overrides.