| 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/*-internals for private modules if they need to be shared between multiple @xxx scope npm packages. alpha version.@company/internal-* for infra.@company/private-* for logic only used inside the repository.Following are proposed sections, to be discussed during code infra sync before promoting.
"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): First node.js version that supports ESM or lower (v14). Also what we promote on our docs. Note: Updating this requires a semver major.
<aside> 📋
Why? It's a react library, it runs primarily in browsers. SSR is only a subset of users, no need to overdo it.
</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? seems best practice in the community.
</aside>