| 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.