Over the years working on large React applications, one problem kept growing quietly in the background:
frontend dependency fragmentation.
A typical app often ends up with:
- one package for components
- another for hooks
- another for utilities
- another for icons
- another for tokens/themes
Initially it feels fine.
But as applications and teams scale, the cost compounds:
- inconsistent APIs
- larger bundles
- duplicate abstractions
- version conflicts
- fragmented documentation
- different engineering philosophies across packages
I started noticing that frontend teams spend a surprising amount of time stitching ecosystems together instead of building products.
That got me thinking:
Why are components, hooks, utilities, tokens, and React helpers usually treated as disconnected ecosystems?
Lately I’ve been experimenting with consolidating these layers into a single tree-shakeable React ecosystem so everything is:
- versioned together
- documented together
- designed together
- optimized together
Interestingly, the hardest part hasn’t been building components.
It has been:
- preserving tree-shaking properly
- avoiding side effects
- maintaining API consistency
- keeping bundle output clean
- balancing flexibility vs cohesion
Curious how other frontend engineers here think about this problem.
Do you prefer:
- specialized independent packages or
- more unified frontend ecosystems?