Upgrading @croct/plug-next across a major version, what usually breaks?
I maintain a Next.js app that has been on the same @croct/plug-next version for about a year. Reading through the changelogs before jumping the major, I can see at least one export was renamed along the way, which makes me suspect there are other renames I have not spotted.
For those who have done this jump on a real codebase: what is the practical checklist? I would rather walk through a known list than discover each break one failing build at a time.
1 answer
The checklist for a year-old version is short:
-
The rename you spotted is almost certainly middleware to proxy. The current setup is:
export {proxy} from '@croct/plug-next/proxy';If you compose your own middleware logic, it wraps with withCroct and you export the result. Older tutorials still show the middleware export, so update from the docs rather than blog posts.
-
After updating the package, run npx croct upgrade. It bumps the slot and component version specifiers in croct.json5 and regenerates slots.d.ts. This is the step people skip: with fresh types, any content schema drift from the past year surfaces as type errors at compile time instead of as runtime surprises.
-
Run the build and let TypeScript walk you through whatever the regenerated types flag. In practice that list is the real diff between your code and the current content model.
That is the whole procedure. The SDK surface itself (fetchContent, hooks, provider) has been stable across recent majors.