chore(deps): upgrade next.js to 16.2.4#4460
Conversation
- Bump next and @next/env to 16.2.4 across root, apps/sim, apps/docs - Replace next-runtime-env's env() helper (calls unstable_noStore(), rejected by Next 16.2 outside request scope) with a direct window.__ENV / process.env getter - Add export const dynamic = 'force-dynamic' on landing /privacy and /terms pages so NEXT_PUBLIC_* runtime env reads aren't baked at build
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryMedium Risk Overview Reworks public env resolution to avoid Reviewed by Cursor Bugbot for commit 3abdafc. Configure here. |
Greptile SummaryThis PR upgrades Next.js from 16.1.6 to 16.2.4 across the monorepo and adapts the codebase to Next 16.2's stricter rules around
Confidence Score: 5/5Safe to merge — the upgrade is mechanical and well-reasoned, with no changes to auth, data paths, or API contracts. All changed files address Next 16.2 compatibility in straightforward ways. The env.ts rewrite is correct for both server and client paths. The force-dynamic additions are audited and necessary. The Suspense fix for OAuthConsentPage is the canonical pattern. The two observations are minor behavioral trade-offs with negligible real-world impact for this use case. No files require special attention; the navbar's isBrowsingHome one-shot read and the env.ts client fallback are worth keeping in mind if landing page navigation behavior changes in future. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["getEnv called"] --> B{"typeof window === 'undefined'?"}
B -- "Yes / Server" --> C["return process.env value"]
B -- "No / Client" --> D{"window.__ENV has variable?"}
D -- Yes --> E["return window.__ENV value"]
D -- No --> F["return process.env fallback (no-op in browser)"]
G["next.config.ts"] --> H["Uses process.env.NEXT_PUBLIC_BRAND_* directly"]
I["OAuthConsentPage"] --> J["Suspense wraps useSearchParams"]
K["Navbar"] --> L["useEffect on mount reads window.location.search once"]
M["privacy / terms / manifest / reset-password / invite / unsubscribe"] --> N["force-dynamic added"]
Reviews (5): Last reviewed commit: "fix(navbar): preserve SSR HTML, drop Sus..." | Re-trigger Greptile |
Without this, NEXT_PUBLIC_BRAND_* values are baked into the manifest at build time. Pairs with the next-runtime-env removal in the prior commit, restoring Docker runtime injection for whitelabel deployments.
|
@greptile |
|
@cursor review |
Next 16.2's stricter prerender check fails the build when useSearchParams() is used without a Suspense boundary. Splits the client component into an outer wrapper and inner body.
Client components in (landing) (e.g. Navbar) read NEXT_PUBLIC_BRAND_* via getEnv. Without this, SSR prerender would bake the build-time process.env values into HTML, mismatching window.__ENV after hydration in Docker runtime-env deployments. Cascades to all landing routes via the layout.
|
@greptile |
|
@cursor review |
Cascading force-dynamic neutered dynamicParams = false + generateStaticParams on /blog/[slug], /integrations/[slug], /models/[provider], /models/[provider]/[model] — killing static prerender for SEO-critical pages. The hydration concern only materializes for whitelabel Docker deployments where build-time and runtime NEXT_PUBLIC_BRAND_* differ; those deployments can set the vars at build instead. Keeping force-dynamic on /privacy, /terms, and /manifest where it actually matters.
Next 16.2 fails the build when a client component using useSearchParams() is statically prerendered without a Suspense boundary. - Wrap landing Navbar in Suspense (imported by /oauth/consent and other pages) - Add force-dynamic to reset-password, invite/[id], and unsubscribe pages whose client bodies call useSearchParams
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit e037cb8. Configure here.
|
@greptile |
|
@cursor review |
Reading useSearchParams() forced a Suspense fallback that emitted no navbar HTML during SSR — leaving crawlers and no-JS users without nav. The 'home' query param only affects client-side link targets, so read it from window.location in an effect after hydration. Restores full SSR navbar markup.
|
@greptile |
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 3abdafc. Configure here.
The force-dynamic export name is self-documenting; the remaining env.ts comment is tightened to the essential WHY (why we don't use next-runtime-env's helper).
Summary
nextand@next/envto 16.2.4 across root,apps/sim, andapps/docsnext-runtime-env'senv()helper with a directwindow.__ENV/process.envgetter — itsunstable_noStore()call is rejected by Next 16.2 outside request scopeexport const dynamic = 'force-dynamic'to landing/privacyand/termssoNEXT_PUBLIC_*runtime env reads aren't baked at buildType of Change
Testing
Tested manually —
next build,tsc --noEmit,check:api-validation, and the full test suite (5695 tests) pass.Checklist