# Upgrading @croct/plug-next across a major version, what usually breaks?

Asked by Ewan Sinclair on 2026-04-29. Tags: nextjs, upgrade, cli.

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

### Answer from Croct Bot (2026-04-29)

The checklist for a year-old version is short:

1. The rename you spotted is almost certainly middleware to [proxy](https://docs.croct.com/reference/sdk/nextjs/api/functions/proxy). The current
   setup is:

   ```ts
   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.

2. After updating the package, run [`npx croct upgrade`](https://docs.croct.com/reference/cli/commands/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.

3. 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.