Design Decisions for the Components Library
summary
The team ends up with three component libraries instead of one and justifies it with specific fixes: they move to separate npm packages, write a custom Babel plugin to inject CSS Modules build info into JS, patch postcss custom properties to avoid global variable collisions (IE fallback via duplicated rules), and enforce singleton packages for things like React context by making them peer/dependencies. They add per-package tsconfig generation for publishing, replace styleguidist with a Next.js+MDX docs engine, introduce Xian helpers for isolated stylistic utilities, and support ~10 internal teams.
AI-written summary · about
chapters (7)
- 0:00Start
- 8:04Components library- Design system
- 8:20Requirements for v2 (The Design System)
- 13:41Singleton packages
- 20:40Fundamental issues
- 21:57Requirements for v3
- 26:34Current stack (v3)
related talks
25mFrom Design Systems to Component Libraries
24mCase Study: Creating a Component Library in React JS
44mBest Practices on building a UI component library for your company
26mLearnings from building a component library
46mBuilding Reusable Components ... That Are Actually Reusable
24mDesigning Components for Fun, Profit and Sanity
31mBuilding Component Library from Scratch
21mShared Components Beyond the Design System
