Use React 19 stable for related packages and types

[S-YOU]

Follow up to this PR: #73564, updated package that can be updated to stable version instead of RC.

[ijjk]

Allow CI Workflow Run

• approve CI run for commit: e080561

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[ijjk]

Allow CI Workflow Run

• approve CI run for commit: e080561

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/react-server-dom-turbopack@19.0.0	None	+1	114 kB
npm/react-server-dom-webpack@19.0.0	None	+1	114 kB

🚮 Removed packages: npm/react-dom@19.0.0-rc-1c9b1387-20241204, npm/react-is@19.0.0-rc-1c9b1387-20241204, npm/react-server-dom-turbopack@19.0.0-rc-1c9b1387-20241204, npm/react-server-dom-webpack@19.0.0-rc-1c9b1387-20241204, npm/react@19.0.0-rc-1c9b1387-20241204

View full report↗︎

[eps1lon]

You changed the vendored version of React we use in the App Router. It's automatically updated with the latest canary not latest stable (i.e. latest).

[karlhorky]

@eps1lon is it planned to go back to non-canary versions of react and react-dom in the user's / project's package.json file?

Eg. usage of react@19.0.0 and react-dom@19.0.0 in <project root>/package.json, even though Next.js uses a different canary version internally?

The reason I ask is that automated npm package upgraders like Renovate bot and Dependabot will automatically bump the versions of next, react and react-dom in an indiscriminate way - they will just bump to the latest versions. These upgrades often cause mismatches between the Next.js-internal versions of react/react-dom and the project's package.json versions of react/react-dom, causing build failures. This has happened to us at least 10 times in our projects in the last months/years.

Why not just disable the automated upgrades for react/react-dom? Because that will still fail over time, as newly auto-upgraded versions of Next.js rely internally on new react/react-dom versions, causing a mismatch with the stale versions from the time of disabling.

I have come up with a workaround for this in the interim - using GitHub Actions workflows and a shell script to fix the version numbers after the bots upgrade to mismatching react/react-dom in package.json:

• https://github.com/karlhorky/next-js-tricks?tab=readme-ov-file#github-actions-automated-upgrades-to-nextjs-internal-react-versions

But ideally there would be a more bulletproof way to allow these upgrader bots to upgrade to the latest stable versions of all packages (eg. as it was before Next.js started requiring canary versions of react/react-dom in the project package.json).

Alternative: Next.js could stop requiring react/react-dom in the project package.json and only use its internal versions (maybe also using peerDependencies in some way)

[eps1lon]

is it planned to go back to non-canary versions of react and react-dom in the user's / project's package.json file?

Yes.

If Renovate is doing upgrades that create conflicting peer dependencies, I'd file that against their repo.

The version of React in peerDependencies is for Pages router so we can't just drop it.

These upgrades often cause mismatches between the Next.js-internal versions of react/react-dom and the project's package.json versions of react/react-dom, causing build failures.

I don't see how this would be frequent. The latest version of Next.js was always immediately supporting the latest version of React so there should rarely be a long period of mismatch.

[karlhorky]

is it planned to go back to non-canary versions of react and react-dom in the user's / project's package.json file?

Yes.

Oh nice, I saw yesterday that the latest reproduction template already uses react@19.0.0 and react-dom@19.0.0 in the project package.json with the latest reproduction template:

• https://codesandbox.io/p/sandbox/github/karlhorky/mdx-tricks/tree/main/interpolation-in-code-blocks
• Originally found this for my example sandbox in https://github.com/karlhorky/mdx-tricks#interpolation-in-code-blocks

Can confirm that create-next-app also creates a project with react@19.0.0 and react-dom@19.0.0 present in the project package.json:

➜  p mkdir a
➜  p cd a
➜  a pnpm create next-app@latest . --app --no-turbopack --no-src-dir --no-eslint --import-alias @/\* --no-tailwind --typescript

.../193afd0e5d9-9dc4                     |   +1 +
.../193afd0e5d9-9dc4                     | Progress: resolved 1, reused 0, downloaded 1, added 1, done
Creating a new Next.js app in /Users/k/p/a.

Using pnpm.

Initializing project with template: app


Installing dependencies:
- react
- react-dom
- next

Installing devDependencies:
- typescript
- @types/node
- @types/react
- @types/react-dom

! The local project doesn't define a 'packageManager' field. Corepack will now add one referencing pnpm@9.14.4+sha512.c8180b3fbe4e4bca02c94234717896b5529740a6cbadf19fa78254270403ea2f27d4e1d46a08a0f56c89b63dc8ebfd3ee53326da720273794e6200fcf0d184ab.
! For more details about this field, consult the documentation at https://nodejs.org/api/packages.html#packagemanager

Packages: +35
+++++++++++++++++++++++++++++++++++
Progress: resolved 60, reused 34, downloaded 2, added 35, done

dependencies:
+ next 15.0.4
+ react 19.0.0
+ react-dom 19.0.0

devDependencies:
+ @types/node 20.17.9 (22.10.1 is available)
+ @types/react 19.0.1
+ @types/react-dom 19.0.2
+ typescript 5.7.2

Done in 2.7s
Initialized a git repository.

Success! Created a at /Users/k/p/a

➜  a git:(main) cat package.json
{
  "name": "a",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "react": "^19.0.0",
    "react-dom": "^19.0.0",
    "next": "15.0.4"
  },
  "devDependencies": {
    "typescript": "^5",
    "@types/node": "^20",
    "@types/react": "^19",
    "@types/react-dom": "^19"
  },
  "packageManager": "pnpm@9.14.4+sha512.c8180b3fbe4e4bca02c94234717896b5529740a6cbadf19fa78254270403ea2f27d4e1d46a08a0f56c89b63dc8ebfd3ee53326da720273794e6200fcf0d184ab"
}

I'll upgrade to the non-canary react and react-dom versions and drop our GitHub Actions workflow 🎉