What is Component Library?

What is a Component Library?

A component library is a versioned collection of reusable UI building blocks — buttons, modals, form inputs, navigation elements — packaged as importable code that teams share across projects. Unlike a full design system, which includes principles, tokens, and guidelines, a component library is specifically the coded artifact: the React components, the Vue SFCs, the Web Components. Libraries like Radix UI (first stable release 2022), Shadcn/ui (2023), and MUI (originally Material-UI, launched 2014) are well-known public examples. Internally, most product companies maintain a private component library tailored to their brand. We've shipped component libraries on 50+ client projects, typically using React with TypeScript and Storybook for documentation. The main value is straightforward: build a button once, use it 400 times, fix it in one place. A well-maintained library cuts new feature development time by 30–50% after the initial investment.

How it works

A component library is a standalone package — usually published to npm (public or private registry) — that exports UI components. Here's the typical architecture:

1. Component code: Each component lives in its own directory with the implementation, types, tests, and styles.
2. Build step: A bundler like tsup, Rollup, or Vite's library mode compiles the source into ESM and CJS outputs.
3. Documentation: Storybook (v8.x as of 2025) renders each component in isolation with knobs for props.
4. Versioning: Semantic versioning via changesets or standard-version. Breaking prop changes = major bump.

A minimal component structure looks like this:

/src
  /Button
    Button.tsx
    Button.stories.tsx
    Button.test.tsx
    Button.module.css
    index.ts
  /Input
    ...
  index.ts       // barrel export
package.json
tsconfig.json

Consumer apps install the package and import components:

import { Button, Input } from '@acme/ui';

export function LoginForm() {
  return (
    <form>
      <Input label="Email" type="email" />
      <Button variant="primary">Sign In</Button>
    </form>
  );
}

Design tokens (colors, spacing, typography scales) are typically injected via CSS custom properties or a theme provider, keeping the library decoupled from any single brand. This separation matters — it's what makes the library reusable across multiple products or clients.

When to use it

A component library pays for itself once you have more than one app or more than three developers touching UI code.

Use a component library when:

• You maintain 2+ web applications that should look and behave identically
• Your team has grown past 3–4 frontend developers and inconsistency is creeping in
• You're building a SaaS product with a customer-facing app and an admin dashboard
• You want to enforce accessibility defaults (focus management, ARIA attributes) in one place

Skip it (or keep it simple) when:

• You have a single small app with one developer — a shared /components folder is fine
• The project is a short-lived marketing site with no long-term maintenance
• You don't have the capacity to maintain versioning and documentation — an unmaintained library is worse than no library

Our preferred approach: start with a /components directory inside the monorepo, extract to a proper package only when the second consumer app appears.

Component Library vs alternatives

A component library is one layer of a design system. If someone says "we have a design system" but they only have coded components and no design tokens, guidelines, or contribution process, they have a component library. That's fine — it's still valuable. Just call it what it is.

Real-world example

We built an internal component library for a B2B SaaS client running three Next.js apps (customer portal, admin dashboard, onboarding wizard). The library contained 47 components, published to a private GitHub Packages npm registry. We used Radix UI primitives as the accessible base, styled with Tailwind CSS and CSS custom properties for theming. Storybook 8.1 served as the living documentation. After the initial 6-week build, the client's team reported that new feature pages went from ~3 days to ~1 day of frontend work. Chromatic visual regression testing caught 12 unintentional style breaks in the first quarter alone. The library is now at v4.2 with 380+ weekly internal installs across their monorepo.