Node.js release schedule: https://nodejs.org/en/about/previous-releases

Products

We support Node.js on our product as low as their maintenance mode version. For example: https://mui.com/material-ui/getting-started/supported-platforms/#server.

Anytime we do a major release, we are likely to drop support for the unmaintained Node.js versions.

<aside> 💡

Note: We don’t set an engines field for UI libraries. The engines field is about where the package can be installed. Not where it runs. UI libraries definitely run on the browser, but only optionally on Node.js. Users that set up a test environment or SSR already are tasked with the duty of matching their test environment to the browser target we support. Node.js support is exclusively communicated to the users through the docs, just like we do for browser support.

</aside>

Internal tools

We try to replicate Products to dogfood our product, but we are flexible.

We will upgrade to the LTS Node.js version if there is enough gain for it, and only upgrade to the Active version if there is a strong upside.

For example, during the CJS → ESM migration period, we diverged the Node.js version to simplify operations. Think like this: “What’s faster: fix a few SSR regressions or have to handle CJS support in our internal tool?” The former.

When we use more recent versions of Node.js for internal tools, we add a simple smoke test with the older version in Products that we support to decrease the likelihood that our users will experience regressions.