A content publish broke my build because the slot type changed, how do I stop that?
A colleague published a schema change on one of our slots this morning, and my very next build started failing because the content shape had changed under me. Nothing in my code changed, the behaviour just shifted because the slot did.
Digging in, I realised I was fetching the slot without pinning a version, so I was effectively tracking whatever the latest schema happens to be. What is the right way to stop a publish from breaking builds like this?
2 answers
That is exactly it: a slot id with no version resolves to latest, so a published schema change takes effect immediately and can break code that was written against the old shape. Nothing in your repo has to change for it to happen, which is what makes it feel like it came out of nowhere.
The fix is to pin the version. You can pin it in the slot id itself:
const {content} = await fetchContent('home-hero@2');or set the specifier in croct.json5 so it applies across the project. Either way you can use a major (2) or a major.minor (2.1) specifier depending on how tightly you want to track. Once pinned, a colleague publishing a new version no longer moves your build until you choose to bump.
If you want to see which version is actually being served at runtime, the content payload carries a _component like "home-hero@2", so you can read that back and confirm.
After you pin, regenerate slots.d.ts so the generated types line up with the pinned version rather than latest. Otherwise the code pins one version and the declarations still describe another, and you get a mismatch that is annoying to chase. Same class of stale-codegen issue as Added a new slot in the dashboard, TypeScript says the slot ID does not exist.
Pinned in croct.json5, regenerated the declarations, and builds have been stable through two more publishes since. No surprises this time, thank you.