If I change a Sanity component's fields, does it break the mapped Croct slot?
We iterate on our Sanity component schemas fairly often, adding and renaming fields as the design evolves. My worry is that editing a component's fields silently breaks the Croct slot it is mapped to, and we only find out in production.
How does versioning handle that kind of schema drift?
1 answer
Slots and components in Croct are versioned, so a schema change does not silently break anything by itself. Changing the fields creates a new version, and the old versions keep serving. What decides whether your app breaks is how your code references the slot.
Your code pins a version, either as a major like home-hero@2 or a major.minor. As long as you pin, a new version can exist without affecting the running app. The risk case is an unpinned slot, which resolves to @latest: a publish can then take effect immediately and break the app, because the payload shape shifts under code that expected the old one. So pin your versions and bump deliberately.
Two things that keep this smooth in practice: commit the generated slots.d.ts so your types stay aligned with the pinned version and a drift shows up as a type error rather than a runtime surprise, and remember that preview requires the slot versions to match, so a mismatch is caught before it ships. Throughout, your existing Sanity content stays as the fallback.
See content preview for the version-match requirement and the CLI configuration reference for how version specifiers are pinned.