Background
@fedify/next declares its next peer dependency as ^15.4.6 (via the pnpm catalog entry in pnpm-workspace.yaml), which caps it below Next.js 16. Next.js 16 has been the default that create-next-app@latest installs since late 2025, and at the time of writing the stable release is 16.2.4. The fedify init -w next path in @fedify/init shells out to create-next-app, so anyone following the quickstart today ends up with Next.js 16 in package.json and a peer-dep mismatch as soon as @fedify/next is added.
User-visible symptom
Running fedify init -w next -p npm -k in-memory -m in-process <name> against create-next-app 16.x produces an ERESOLVE error at the end of the scaffolding step. The project is unusable until the user manually edits package.json to downgrade next, react, react-dom, and eslint-config-next to the 15.x line, then re-runs npm install. The new Building a threadiverse community platform tutorial documents this workaround in its Setting up the development environment chapter; see the callout under fedify init to initialize the project (see #710).
Why this matters
fedify init is the first thing a reader does in the Next.js-flavoured tutorial, and a hard install failure immediately after running the command sets a bad tone. It also erodes our claim in the docs that Fedify's Next.js integration is a first-class option: currently it's a first-class option for the previous major of Next.js. Every week we delay, more readers get caught by the mismatch, and the tutorial has to carry a workaround block that will silently rot once Next.js 17 lands.
Proposed changes
- Widen the
next catalog entry in pnpm-workspace.yaml from ^15.4.6 to a range that covers both 15.x and 16.x (">=15.4.6 <17" or equivalent). The @fedify/next package.json peer dependency inherits from the catalog and so covers the new range automatically.
- Audit the tiny surface that packages/next/src/index.ts uses from Next.js (essentially
NextResponse from next/server and the middleware matcher shape from middleware.ts.tpl) against the Next.js 16 release notes. Either the modules have compatible 15/16 behavior, or we need a conditional import. In my skim of the source I didn't see anything obviously 15.x-specific, but we should confirm rather than assume.
- Add an end-to-end check to
mise test:init and mise test:examples that runs the Next.js generator with the latest create-next-app and boots the resulting app, so a future major bump in Next.js fails CI instead of failing the user's first install.
- Unpin examples/next15-app-router (or rename/clone it) so we have a coverage matrix against both 15.x and 16.x; the smoke harness in test/smoke/ already handles multi-runtime testing and could be extended here.
- Once
@fedify/next ships with the widened range, drop the workaround block from the threadiverse tutorial and update the prereq note to say that Fedify supports Next.js 15.4+ including 16.x. The tutorial already calls this out explicitly (This workaround will go away once Fedify ships support for Next.js 16.), so the edit is a one-line removal.
Scope (what this issue is not)
Porting the example apps to exercise Next.js 16-specific features (turbopack-by-default, new middleware runtime knobs, the cacheComponents API, etc.) is a separate follow-up. For this issue, the goal is the minimum delta that lets @fedify/next install cleanly against Next.js 16 and keep behaving the same way it does against 15.x.
Acceptance criteria
Background
@fedify/nextdeclares itsnextpeer dependency as^15.4.6(via the pnpm catalog entry in pnpm-workspace.yaml), which caps it below Next.js 16. Next.js 16 has been the default thatcreate-next-app@latestinstalls since late 2025, and at the time of writing the stable release is 16.2.4. Thefedify init -w nextpath in@fedify/initshells out tocreate-next-app, so anyone following the quickstart today ends up with Next.js 16 in package.json and a peer-dep mismatch as soon as@fedify/nextis added.User-visible symptom
Running
fedify init -w next -p npm -k in-memory -m in-process <name>againstcreate-next-app16.x produces anERESOLVEerror at the end of the scaffolding step. The project is unusable until the user manually edits package.json to downgradenext,react,react-dom, andeslint-config-nextto the 15.x line, then re-runsnpm install. The new Building a threadiverse community platform tutorial documents this workaround in its Setting up the development environment chapter; see the callout underfedify initto initialize the project (see #710).Why this matters
fedify initis the first thing a reader does in the Next.js-flavoured tutorial, and a hard install failure immediately after running the command sets a bad tone. It also erodes our claim in the docs that Fedify's Next.js integration is a first-class option: currently it's a first-class option for the previous major of Next.js. Every week we delay, more readers get caught by the mismatch, and the tutorial has to carry a workaround block that will silently rot once Next.js 17 lands.Proposed changes
nextcatalog entry in pnpm-workspace.yaml from^15.4.6to a range that covers both 15.x and 16.x (">=15.4.6 <17"or equivalent). The@fedify/nextpackage.json peer dependency inherits from the catalog and so covers the new range automatically.NextResponsefromnext/serverand the middleware matcher shape from middleware.ts.tpl) against the Next.js 16 release notes. Either the modules have compatible 15/16 behavior, or we need a conditional import. In my skim of the source I didn't see anything obviously 15.x-specific, but we should confirm rather than assume.mise test:initandmise test:examplesthat runs the Next.js generator with the latestcreate-next-appand boots the resulting app, so a future major bump in Next.js fails CI instead of failing the user's first install.@fedify/nextships with the widened range, drop the workaround block from the threadiverse tutorial and update the prereq note to say that Fedify supports Next.js 15.4+ including 16.x. The tutorial already calls this out explicitly (This workaround will go away once Fedify ships support for Next.js 16.), so the edit is a one-line removal.Scope (what this issue is not)
Porting the example apps to exercise Next.js 16-specific features (turbopack-by-default, new middleware runtime knobs, the cacheComponents API, etc.) is a separate follow-up. For this issue, the goal is the minimum delta that lets
@fedify/nextinstall cleanly against Next.js 16 and keep behaving the same way it does against 15.x.Acceptance criteria
fedify init -w next -p npmagainst the latestcreate-next-appcompletes withoutERESOLVE, and the generated project runsnpm run devsuccessfully.mise run checkandmise run test:initpass with the widened peer dependency.