For a component library, what are the trade-offs between publishing one package for all components and publishing one package per component?

## The two layouts A **component library** can be published as: - **One package** containing every component, versioned as a whole. - **One package per component** - a button package, a plan-card package, a data-usage-meter package - each with its own version. The choice looks like an engineering detail, but it decides what consuming teams experience at every upgrade. ## Side by side | Concern | One package | One package per component | |---|---|---| | Install and upgrade | One dependency, one step | Many dependencies, many steps | | Versioning | One coherent version | Independent versions per component | | Consistency on one screen | Guaranteed | Depends on consumers keeping versions aligned | | Shared internals | Loaded once | May load in several versions | | Bundle size | Small if the package tree-shakes | Small by construction | | Release overhead for the library | One release | Many coordinated releases | One caveat on the bundle row: a single package ships only what the app imports when it is tree-shakeable. If it is not, every component rides along, which is often the real motivation behind splitting. ## What goes wrong with per-component packages - **Version skew.** Components contain components: a plan card renders a button and a badge. If the app pins the plan card at one version and the button at another, one screen shows two generations of the same design. - **Duplicated internals.** Shared utilities - focus management, positioning, token access - may be pulled in at several versions, growing the bundle and sometimes splitting shared state. - **Upgrade fatigue.** Consumers face dozens of version bumps instead of one, and tend to stop upgrading at all. - **Compatibility matrices.** The library must reason about which component versions work together, a problem a single version never has. ## The common middle ground 1. **One package, per-component entry points.** Consumers import each component directly, getting small imports with one coherent version. 2. **Separate packages for separate concerns.** Design tokens, icons and fonts often ship on their own because non-component consumers - a marketing site, a native app, an email template - need them without the components. 3. **Isolate heavy optional components.** A data-usage chart that depends on a large rendering engine gets its own package, so apps that never chart never install it. 4. **If per-component packages are unavoidable, release them in lockstep** with one shared version, so 'version 7' means the same thing for every component. ## Changing layouts later Moving between layouts is itself expensive, which is a reason to choose deliberately early: - **Splitting one package into many** changes every import path in every consuming app, so it arrives as a breaking release, usually with an automated migration. - **Merging many packages into one** removes version skew in a single step, but consumers pinned at different component versions must jump to one aligned release at once. - **Adding entry points** to a single package is additive and backward-compatible, which makes it the cheapest direction to evolve. The cheapest path is usually to start with one package and entry points, and split out only the parts that later prove to need independence. ## When independent packages do make sense - A very large organisation where different teams own components with genuinely different release cadences. - Components with heavy or platform-specific dependencies most consumers never need. - Separate platforms: native mobile components usually ship as their own packages alongside, not inside, the web library, sharing tokens and specifications rather than code. The principle interviewers listen for: package boundaries should follow what consumers need to version independently, and for components that compose one another, that is rarely each component on its own.