Governing a shared Storyblok component library across three brand sites with Croct
I maintain one component library consumed by three brand sites, each with its own Storyblok space and its own release cadence. We are introducing Croct across all three, and my concern is evolution, not setup.
The failure mode I want to design against: the library team evolves a component schema (say the hero gains a badge field), brand A upgrades immediately, brand C ships quarterly. If slot schemas move in lockstep with the library, a change for brand A could break brand C's rendering.
How do component schemas and slot versioning behave when the same logical component evolves at different speeds across consumers? Is there an established pattern for pinning per site, and what governance rules have worked for others running a shared library
2 answers
The versioning model is built for exactly this, so your failure mode is avoidable with one governance rule.
In Croct, components are defined by component schemas aligned to your design system, and each slot is bound to one component. When the library team changes a schema, that creates a new version, and here is the part that matters for you: old versions keep serving. Nothing forces consumers to move.
The consumer side controls its own pace by pinning versions in code, like home-hero@2. Brand A pins @3 the day the badge field ships, brand C stays on @2 until its quarterly release, and both keep working against the same logical component.
The one rule to enforce across all three codebases: never use an unpinned slot ID. Unpinned IDs resolve to @latest, so a schema publish would take effect immediately for any consumer that did not pin, which is precisely the brand-C breakage you described. Make the pin a lint rule or a code review checklist item and the shared library evolves safely.
Can confirm the pinning discipline is the whole game. We run a similar multi-site setup and treat slot version bumps like dependency upgrades: the library changelog lists which slot versions a release introduces, and each site upgrades its pins in a normal PR on its own schedule. Old versions kept serving for months in our case without issues, so slow consumers are genuinely safe, not just tolerated.