| 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 public dependency that use an unstable API of another public dependency must pin the version. It's important so breaking changes don't propagate from one package to another. |
| “internal” | ✅ | No | No | Avoid duplication of code between npm packages. | package name: | |
@project-name/internals for logic used by public packages. |
||||||
@company-name/internal-* for infra |
Dependencies using must pin their version. | |||||
| “private” | No | No | No | For logic only used in the git repository, workspace local packages, examples. | - if it needs to be referenced: | |
private: true property in |
||||||
| package.json. | ||||||
@company-name/private-* |
@product-name (the organization name) It is named after the name of the open-source project. If the package is meant to be used by MUIers, it should use the company's org name. Typically for infra (e.g., docs-infra, code-infra).@product-name/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-name/utils for public modules if they need to be shared between multiple @xxx scope npm packages.@product-name/**/unstable_** If that module is getting replaced by a new one or isn’t stable yet.@product-name/*-internals for private modules if they need to be shared between multiple @xxx scope npm packages. alpha version.@company-name/internal-* for infra.@company-name/private-* for logic only used inside the repository.