| Name | Published on npm | Imported by developers | Follow semver | Use cases | API naming | Notes |
|---|---|---|---|---|---|---|
| “public” | ✅ | ✅ | ✅ | Our product. | Nothing special. | |
| “unstable” | ✅ | ✅ | No | API we want to try out with the community. They could become stable. | Same as above, but have modules exported with a prefix: unstable_ . |
A stable dependency that use an unstable API of another dependency must pin the version used. It's important so breaking changes don't propagate from one package to another. |
| “internal” | ✅ | No | No | Avoid duplication of code between our npm packages. | - internal APIs for packages: @product/internals , can be dependency of public packages, must be pinned. |
@company/internal-* , can’t be a dependency of public and unstable packages. | Dependencies using must pin their version. This is needed as those packages don’t follow semver. They don’t follow semver so we can iterate without having to think about breaking changes. |
| “private” | No | No | No | For logic only used in the git repository, workspace local packages, examples. | - (most likely) if it doesn't needs to be referenced: no nameprivate: true property in
package.json.
@github-repository-slug/private-*
| |@product (the npm organization name) It is named after the open-source project. If the packages are intended for MUIers, they should use the company's organizational name. Typically for infra (e.g., docs-infra, code-infra).@product/MAIN: default to no new npm packages. If the module can stay in the main npm package, and simply be exported if public and not be exported if private, do this.@product/utils for public modules if they need to be shared between multiple @xxx scope npm packages.@product/**/unstable_** If that module is getting replaced by a new one, or isn’t stable yet.@product/**-internal** for private modules if they need to be shared between multiple @xxx scope npm packages. alpha version.@company/internal-** for code shared between repositories.@company/private-** for logic only used inside the repository."engines" fieldnodeFor versions see https://nodejs.org/en/about/previous-releases
Dev environment (workspace root package.json): "Active LTS" or lower.
<aside> 📋
Why? Maintainers/contributors should take the effort to stay up-to-date; we shouldn't waste code-infra time on backporting fixes and compatibility modes for outdated Node.js versions.
</aside>
React libraries we publish (individual package.json): Not set
<aside> 📋
Why? It's a React library; it runs primarily in browsers. SSR is only a subset of users; there's no need to document it differently than we do for browsers.
</aside>
CLI tools, node.js libraries, babel/eslint plugins we publish publicly (individual package.json): "Maintenance LTS" or lower. Note: Updating this requires a semver major.
<aside> 📋
Why? It seems to be the best practice in the community.
</aside>
@mui/internal-* Node.js tooling (individual package.json): same as “Dev environment”.
<aside> 📋
Why? unused except in an environment that already has this restriction.
</aside>
engines.node in package.json is an indicator that the CI runs on the exact minimum node version as specified in the field, ie, "engines.node": ">=22.18" means that CI is on 22.18.0 and devs are free to install any node version ≥22.18 locally.