[examples] Use Next.js 14 on examples

[DiegoAndai]

There are two separate but related issues:

1. The Next.js examples point to "react": "latest" and "react-dom": "latest". In theory, both should be "rc" until React 19 is stable (then it becomes "latest"). Next.js 15 is constantly updating to the latest "rc" releases.
2. The @mui packages indicate "react": "^17.0.0 || ^18.0.0 || ^19.0.0" as peer dependency (same for react-dom), but npm doesn't recognize the 19.0.0-rc versions to be included in that range, so a warning/error is logged when npm i is run. This doesn't happen with yarn or pnpm.

We could update our Next.js examples to "react": "rc" and our peer dependency ranges to 17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc, but it won't improve anything for our users because:

• The npm warning/error will show anyway as Emotion is using "react": ">=16.8.0" in its peer dependencies (npm doesn't consider 19.0.0-rc.* to be >=16.8.0)
• We would likely want to revert both changes once React 19 is stable. Users who created their projects using our example until this time would have an outdated setup.

My proposal in this PR is to downgrade the examples to Next.js 14 until React 19 is stable.

I also added a link to Next.js upgrade guide to each example's README. The upgrade process is pretty straightforward. It also warns about the npm i issue, so users know what to do: https://nextjs.org/docs/app/building-your-application/upgrading/version-15.

On a related note, pointing to the "latest" version of a framework in our examples seems risky. It seems safer to point to a specific major and update them on major releases to make sure they work with the new major.

[mui-bot]

Netlify deploy preview

https://deploy-preview-44486--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against bb74dcf

[aarongarciah]

Nice!

[samuelsycamore]

On a related note, pointing to the "latest" version of a framework in our examples seems risky. It seems safer to point to a specific major and update them on major releases to make sure they work with the new major.

Agreed—I would always rather have a (potentially slightly outdated) stable integration over the latest release if there's a chance that the latest will be broken (in which case I'll have to downgrade anyway and wait for a fix). I think developers would lose trust if our official examples won't run reliably, so we should be more proactive about maintaining them at specific versions.

[samuelsycamore]

nitpick copyedit for the readme text but tentatively approving 👍

[samuelsycamore]

to make it more explicit that this a link to the Next.js docs

Suggested change

	To upgrade to Next.js 15, please follow their [upgrade guide](https://nextjs.org/docs/app/building-your-application/upgrading/version-15).
	To upgrade to version 15, please follow the [official upgrade guide](https://nextjs.org/docs/app/building-your-application/upgrading/version-15) in the Next.js docs.

[oliviertassinari]

1. The npm warning/error will show anyway as Emotion is using "react": ">=16.8.0" in its peer dependencies (npm doesn't consider 19.0.0-rc.* to be >=16.8.0)

I was confused about this. How so?
For example https://jubianchi.github.io/semver-check/#/%3E%3D16.8.0/19.0.0-rc.1

2. We would likely want to revert both changes once React 19 is stable. Users who created their projects using our example until this time would have an outdated setup.

I would expect the opposite as a developer, I would want to start with Next.js 15. Why would a developer want to start a new project with an older version?
For example, developers are migrating to Next.js 15 faster than they are migrating to Material UI v6, proof: compare https://tools-public.mui.com/prod/pages/npmVersion?package=next, https://tools-public.mui.com/prod/pages/npmVersion?package=@mui/material, with the number of days they were released.

On a related note, pointing to the "latest" version of a framework in our examples seems risky. It seems safer to point to a specific major and update them on major releases to make sure they work with the new major.

This was by design, the objective was to get those reported quickly, so we can fix them in a matter of hours/days rather than weeks.

[DiegoAndai]

@oliviertassinari

I was confused about this. How so?

It's an npm error.

It's the same for ^19.0.0. 19.0.0-rc should be considered in range, yarn and pnpm do consider it, but npm doesn't:

I would expect the opposite as a developer, I would want to start with Next.js 15. Why would a developer want to start a new project with an older version?

I agree, but a more important expectation is for the example to work. We're not ready with React 19 support, as it's not even stable yet, so we shouldn't have examples that users expect to be working using a React version we don't fully support. Even the React 19 types are still coming from a draft PR.

Next.js taking a more aggressive approach to React 19 support, but it's not a strategy we're following (we could, I'm just saying we're not at the moment). Having a major based on an unstable and still changing version of React 19 is risky. If people want to try it at their own risk, they can, that's why the upgrade guide is linked, and that's why we've been incrementally merging React 19 fixes to Material UI.

The user should decide to take this risk.

For example, developers are migrating to Next.js 15 faster than they are migrating to Material UI v6

How is this relevant or comparable? It's difficult to analyze; you could make the argument that it means Material UI users are more risk-averse than Next.js users or care less about being on the latest versions.

This was by design, the objective was to get those reported quickly, so we can fix them in a matter of hours/days rather than weeks.

It's bad design, and it's not even disclosed to users. It pushes users into potentially broken examples to figure out whether it's a problem on their end or ours, which is a very bad experience. This could be one of the first impressions a user gets from Material UI, it should be something we're sure will work.