next-forge

Description Fix npm dependency resolution for generated next-forge projects. The workspaces pin React to , but packages with React and React DOM peer dependencies allow npm to select a newer release. That newer release requires the matching newer React version, producing an conflict with the pinned React version. This change adds a root override at , keeping the React pair aligned across every workspace. Related Issues Closes #753 Checklist [x] My code follows the code style of this project. [x] I have performed a self-review of my code. [x] Comments are not applicable to this manifest-only change. [x] Documentation updates are not necessary. [x] I validated the dependency-resolution fix end to end. [x] New and existing tests pass locally. Screenshots (if applicable) Not applicable. Validation Biome check across all 300 tracked files Reproduced the original npm failure and verified the React conflict no longer occurs with the override Additional Notes After resolving this React conflict, npm currently reaches the separate OpenAI/Zod conflict tracked in #743 and #746. Applying that independent override during validation allowed to complete successfully.

Describe the bug Running fails during with ERESOLVE dependency conflict between and . next-forge version I am using version 6.0.3 / latest (via npx) To Reproduce Steps to reproduce the behavior: 1. Run: 2. Name your project 3. Observe install failure during dependency resolution Expected behavior Project should install successfully after initialization. Screenshots Desktop OS: MacOS Browser Chrome Node: v20.19.3 npm: 10.8.2 create-next-app: 16.2.9

Is your feature request related to a problem? Please describe.* next-forge covers the model-call tier through (AI SDK), but has no story for the agent* tier — durable, tool-using backend agents. Eve (Vercel's open-source agent framework) defines exactly that shape, and a next-forge monorepo is where it shines: agent tools can reuse the same workspace packages, Prisma schema, and validated env keys the apps already use. Today, users wiring Eve into a next-forge project hit several undocumented seams. I built and verified the integration end-to-end on a fresh scaffold (pnpm) with , and found: 1. mutates the workspace root — rewrites root ( → , Eve's hard minimum) and appends a dependency-hygiene block to . Surprising if undocumented. 2. guards block agent runtimes — 's root entry (and other packages') carries , which only the Next.js runtime satisfies. Eve agents run on Nitro, so direct imports crash at boot. Workaround: import + directly. 3. Tools must bundle to a single module — dynamic inside a tool fails Eve's build. With those documented, the integration works cleanly: durable sessions with tool calls against , graceful degradation when is absent (matching next-forge's optional-integration philosophy), , typecheck, and all green. Describe the solution you'd like An addon guide — — following the existing addon shape (c15t, Trunk): scaffold as a workspace app, a tool that reuses , evals, client wiring via , and deployment as a separate Vercel project. I have this written and dogfooded, and will attach a PR. Beyond the guide, three deeper (discussion-only, not in the PR) opportunities: 1. First-class in the template, gracefully degrading like every other integration (no → agent disabled). 2. Runtime-neutral entrypoints on packages — e.g. a conditional export or a subpath without the guard, so non-Next server runtimes (agents, workers) can consume them. 3. Node 24 baseline — Eve's floor is Node ≥24; the template currently declares . Describe alternatives you've considered as a thin wrapper (like ): doesn't fit — Eve agents are deployable apps with their own build/deploy lifecycle, not shared libraries. Documenting inside the AI package docs: buries a capability that has its own app-shaped lifecycle. Waiting for Eve GA: the guide pins versions and flags beta status instead; the seams above are worth documenting now.