Publishing a shared component library feels like a milestone, until a single change breaks multiple applications at once.
While working on a monorepo at EPAM Systems powering 8 production applications for a global supply chain platform, we built a shared ecosystem of independently deployable frontend packages: authentication, navigation, app shell, user profile, and UI components. On paper, it promised consistency and speed. In reality, it introduced a new class of problems, subtle, cross-app, and often hard to debug.
A mismatch in React versions led to duplicate instances and unpredictable behavior across apps. Small feature requests from different teams slowly turned shared components into overly flexible, inconsistent abstractions. Even “safe” refactors required coordinating across teams, managing rollouts, and avoiding breaking changes in production systems we didn’t fully control.
This talk goes beyond best practices to explore the real trade-offs of shared frontend architecture at scale. I’ll walk through concrete failures, decisions, and constraints we faced — and the strategies that actually worked: strict dependency contracts, opinionated API design, staged migrations, and clear ownership models.
If you’re building or maintaining shared packages in a monorepo or multi-app ecosystem, this talk will help you avoid common pitfalls and make better architectural decisions — before they impact multiple teams at once.
This talk has been presented at React Advanced 2026, check out the latest edition of this React Conference.
