Should I pin slot versions in my Hydrogen loaders or is @latest fine?
Going through our loaders and I noticed some of our slot ids have no version suffix, just the plain id. That worries me a bit. If a content editor publishes a change that alters the payload shape, does that take effect immediately under a running storefront?
My fear is a publish quietly changing the shape my components expect and breaking prod without a deploy on our side. Should I be pinning versions and if so how do I do that properly, without having to babysit every publish.
2 answers
Your worry is well founded. A slot id with no version means @latest, so a schema change on a publish can take effect immediately, and if the payload shape moves your loader code can break with no deploy on your side.
The fix is to pin the version right in the slot id:
const {content} = await context.croct.fetchContent('home-hero@2');Now a publish that creates a new version does not shift the payload under you. Old versions keep serving, and you move to @3 when you are ready and have updated the code to match. Pinning turns a content publish into a non-event for your running storefront, which is what you want.
Adding the piece that pairs with pinning. The CLI generates a slots.d.ts with the types for your configured slot versions. Commit that file. If you commit it, your build does not need an API fetch to resolve the types, and the checked-in types line up with the versions you pinned, so a mismatch shows up as a type error rather than a runtime surprise.
One more reason to pin while you are at it: preview links require the slot version to match too, so if you leave things on @latest a preview can drift out of sync with what you actually fetch.
Makes sense, pinning everything and committing the generated file. The preview angle I had not thought about, good to know before it bit me