The hidden cost of a component fork
Every fork looks cheap on the day it is made. Here is what it actually costs over two years.
A team needs a slightly different dropdown. The shared component does not support it. Adding support means a design review and a cross-team conversation, so they copy the file, change nine lines, and ship on Thursday. Entirely reasonable, and the beginning of a long, expensive story.
The bill arrives late
The fork does not hurt in month one. It hurts in month fourteen, when a keyboard navigation bug is fixed in the shared component and silently persists in three forks nobody remembers making. Accessibility fixes, security patches and theming changes all stop propagating at the fork boundary.
A fork is a loan against your future maintenance capacity, taken out at a rate nobody quotes you.
Make contributing cheaper than forking
Forks are a symptom, not a discipline problem. If contributing to the shared component takes two weeks and forking takes two hours, people will fork, and they will be right to. The fix is on the system side: a named owner, a same-week review commitment, and an escape hatch — a documented way to extend a component without copying it.
- A named owner with reserved review time each week
- Slot or render-prop escape hatches for genuine one-offs
- A visible list of known forks, reviewed quarterly
- Codemods whenever the shared API changes