How do you keep a growing component library from becoming bloated?

A component library stays lean only through ongoing curation: new components are added against real need, near-duplicates are merged, unused ones are retired, and variants are governed rather than allowed to multiply. A library does not stay healthy because it was set up well. It stays healthy because someone keeps pruning it as it grows. Left alone, a library accretes. Every well-meaning addition that never gets reconciled with what already exists makes the next person’s search longer and the whole thing harder to trust, until people start building their own versions because they cannot find or believe yours.

The mechanism of bloat is the just-add habit. When a new need appears, the path of least resistance is to add a new component to cover it, and on its own that feels responsible. The problem is the accumulation. Nobody checks whether something close already exists, so a near-duplicate is born. Nobody removes the component that nothing uses anymore, so dead weight stays. Nobody asks whether the fifth variant of a card is really distinct or just a slightly different guess, so variants breed. Each individual decision is defensible and the sum is a library where three buttons do almost the same thing, half the components have no current usage, and a newcomer cannot tell which of the four cards is the real one. Growth without governance is exactly how a useful library becomes a junk drawer.

A concrete picture shows the difference curation makes. Imagine a library that, after two years of just adding, contains a Button, a PrimaryButton, an ActionButton, and a CTAButton, each created by a different team for a need that overlapped heavily with the others. A designer who wants a button now faces a decision with no clear answer and often invents a fifth. The curated alternative is one Button with a governed set of variants, where adding a sixth variant requires showing it is genuinely distinct from the five that exist. Same for cards, same for inputs. The lean library is not smaller because it does less. It is smaller because every entry has been checked against what already exists, and the redundant ones were merged out instead of piling up.

The real exception is that pruning is not the same as starving the library, and over-aggressive consolidation can be its own harm. Genuinely distinct needs deserve genuinely distinct components, and forcing two real patterns into one over-configured mega-component to keep the count low produces something nobody can use cleanly. The goal is not the fewest possible components. It is that every component earns its place, so the test for an addition is real, current need that nothing existing already serves, and the test for a merge is genuine duplication, not superficial similarity between things that legitimately differ. Curation cuts both ways: it removes the redundant and keeps the truly distinct.

Retirement deserves its own attention because it is the step teams skip most. Adding feels like progress and removing feels like loss, so unused components linger long after their screens are gone, quietly inflating the search space and the maintenance load. A library that is only ever grown will bloat even if every addition was justified at the time, because needs change and yesterday’s necessary component becomes today’s dead weight. Treating removal as normal maintenance, not as an admission of error, is what keeps the library honest about what is actually in use.

So keep the library lean by pruning as you grow, not by hoping good additions are enough. Make it routine to check for an existing match before adding anything, merge near-duplicates as you find them, retire components that nothing uses, and govern variants so the set stays meaningful instead of multiplying. Give someone clear ownership of that curation, because a library nobody prunes will bloat no matter how carefully it was built.