[v6] Upgrade minimum version of Node.js

[ZeeshanTamboli]

Summary 💡

Node v12 has reached end-of-life rather its ended. https://nodejs.org/en/about/releases/

material-ui/packages/mui-material/package.json

Lines 112 to 113 in ac99485

	"engines": {
	"node": ">=12.0.0"

Examples 🌈

Similar to dropping support for node v10 in #25306.

Motivation 🔦

1. Upgrade CI docker node image etc.

[ZeeshanTamboli]

cc: @mui/core

[michaldudak]

We can use a recent Node version for building the library, but I'd leave Node 12 for tests as we still support it. We will likely drop support for it with the next major version.

[ZeeshanTamboli]

We will likely drop support for it with the next major version.

Maybe we should link this issue in the next major version roadmap. Or somewhere else.

[MonstraG]

Just a quick update, Node.js 16 is now unsupported, so we probably want to bump this up to 18.

https://nodejs.org/en/about/previous-releases

[michaldudak]

v18 is in maintenance mode, so I'd say we should go for 20.

[oliviertassinari]

I fail to see how removing support for the older versions of Node.js is helpful. For example, React has https://unpkg.com/react@18.2.0/package.json:

{
  node: ">=0.10.0"
},

What would be the value?

[michaldudak]

For example, being able to use native ES modules.

[oliviertassinari]

Based on mui/mui-x#10997 (comment), I think we should follow this strategy:

• Get a sense of the ecosystem version distributions
• Have the Node.js version as wide as possible, covering 80-90% of the active version installation
• Upgrade a Node.js version if it falls too low under the above 10% of active version installation (we shouldn't have to spend x2 the effort for 10% of the people who could upgrade Node.js)
• Upgrade a Node.js if it's necessary to solve a concrete problem. e.g. if it prevents us from better supporting native ES modules, then it solves a concrete problem.

The main reason is that it's not really our role to tell developers which Node.js version to use. As a developer, you shouldn't have to upgrade your Node.js version or use a newer version of Material UI if you use a version Node.js version that is not completely outdated, it's friction, not great DX.

This wouldn't be against https://mui.com/material-ui/getting-started/supported-platforms/#server "The objective is to support Node.js down to the last version in maintenance mode", developers won't complain that we support older versions unless it harms the experience with more recent versions.

---

Today, the ecosystem seems to be:

• Next.js: the most used version is v12: https://tools-public.mui.com/prod/pages/npmVersion?package=next. That Next.js version works down to node v12
• Webpack: there are 50% of the users on v4 supports node down to v6
• Vite: most of the users are on v4 which supports node down to v14
• pnpm latest: https://unpkg.com/pnpm@latest/package.json supports node down to v16

So from an ecosystem perspective v12 seems OK but maybe with v14, it would still be on the safe side.

[michaldudak]

There doesn't seem to be an agreement in #40958.

it's not really our role to tell developers which Node.js version to use

Agree, it's not. Node.js itself tells developers which versions not to use by putting them out of maintenance. We can follow their guidance.

I'm not advocating for increasing the minimum version just for the sake of it, but using older versions comes with a couple of issues:

1. We won't be able to use some supporting packages. For example Chai requires v18
2. Old Node versions don't support ESM (or support them with a flag)
3. If we don't test our packages in old versions of Node, how can we say we support them?

[samuelsycamore]

2. Old Node versions don't support ESM (or support them with a flag)

This alone would be a big win! (#39765)

[oliviertassinari]

1. We won't be able to use some supporting packages. For example Chai requires v18

@michaldudak Agree, it makes sense to increase the version of the CI to not fall behind Node.js LTS.

2. Old Node versions don't support ESM (or support them with a flag)

We will see, but I suspect that the ecosystem isn't ready for a ESM only package, so I suspect that v6 would be a hybrid version: https://twitter.com/wooorm/status/1663129796195364865.

3. If we don't test our packages in old versions of Node, how can we say we support them?

So far, we have relied on bug reports, and fixing them.

I imagine that having one smoke server-side rendering test could be enough. Is it worth the effort? If there are users using older versions of Node.js I think so. If there aren't enough developers, then it might not be worth the effort to maintain. Now, honestly, I don't see this as being a lot of work. Create a new npm package, use the build output, run a simple node server that render a few components, see if it fails or if it works.

[Janpot]

Webpack: there are 50% of the users on v4 supports node down to v6

Not sure who's using Node.js v6 and at the same time is serverside rendering React 😄, but I'd love to see how they've got that set up. Webpack is used as well for other purposes than React and those are more than likely the ones v6 support exists for.

it's not really our role to tell developers which Node.js version to use

We do tell them which browsers to use though. When they want to use older than supported browsers they'll have to transpile the packages themselves. One could argue that the same should apply to node.js versions. (although here they'd also have to configure their package manager to ignore the engines field)

For example, being able to use native ES modules.

According to their docs v12 is the first version that declares ESM stable. So I guess there is no real problem on this front?

Anyway, I'm personally with @oliviertassinari here, also leaning towards keeping the engines field for node on a low version in our packages. I don't think at the moment it blocks us from moving forward with anything, but:

• I don't think this restriction should apply to our tooling, i.e. workspace root should be at LTS minimum. At least for security sake.
• I wouldn't phrase this as "We support Node 12", I'd phrase this as "We actively support Node v18, but we're not going to ruin your day if you're on Node 12 and try to install our package". Mainly because it's highly likely you're installing it in Node v12 without the intention to also run it on Node. This is still a frontend lib, they're likely only bundling it in Node 12 with the intention to run it on the web. We need to make a distinction between installation runtime, bundler runtime and execution runtime.

[DiegoAndai]

I'm moving this out of the v6 milestone per the last comment. Upgrading the minimum version of node at this moment doesn't seem to bring any benefit to users, and it's not blocking anything either.

Please let me know if this should be reconsidered.

[oliviertassinari]

Being lazy, and waiting to see the problem, makes sense to me.
No real preferences in either direction since v18 seems quite established as well, unlikely to be a blocker for adoption.

---

I'm amazed by how quickly developers moved in 6 months, compared to #32546 (comment) "Today, the ecosystem seems to be" with today

-Next.js: the most used version is v12. That Next.js version works down to node v12
+Next.js: the most used version is v14. That Next.js version works down to node v18

-Webpack: there are 50% of the users on v4 supports node down to v6
+Webpack: there are 24% of the users on v4 supports node down to v6. v5 supports node down to v10

-Vite: most of the users are on v4 which supports node down to v14
+Vite: most of the users are on v5 which supports node down to v18

-pnpm latest: https://unpkg.com/pnpm@latest/package.json supports node down to v16
+pnpm: most of the users are on v8 which supports node down to v18

https://tools-public.mui.com/prod/pages/npmVersion?package=

[oliviertassinari]

I have just realized that MUI X is on Node.js v14 as their minimum version: mui/mui-x#6966. It feels like we should sync those two so developers have a more consistent experience.

[DiegoAndai]

Updated #42920 to sync version with MUI X

[DiegoAndai]

Merged #42920, Material UI is now synced with MUI X, closing this one.