feat(nextjs): add Pages Router support via /pages module#169
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
Warning Review limit reached
Your plan includes 1 review of capacity. Refill in 35 minutes and 51 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis PR introduces full Next.js Pages Router support to ChangesPages Router Support Implementation & Demo Migration
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly Related PRs
Suggested Labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/nextjs/pages-router/src/pages/client/index.tsx (1)
49-50:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate stale package name in the client demo description.
This text still references
@aura-stack/reacteven though this page now uses@aura-stack/next/client.✏️ Suggested change
- Official Next.js demo to showcase `@aura-stack/react` authentication library with Client Side Rendering + Official Next.js demo to showcase `@aura-stack/next` authentication library with Client Side Rendering🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/nextjs/pages-router/src/pages/client/index.tsx` around lines 49 - 50, Update the demo description string that currently mentions "`@aura-stack/react`" to the correct package name "`@aura-stack/next/client`" so the client demo text in pages/client/index.tsx (the line containing the literal "Official Next.js demo to showcase `@aura-stack/react` authentication library with Client Side Rendering (CSR), for Server-Side Rendering (SSR) visit") reflects the current package; simply replace the package name in that string to "`@aura-stack/next/client`".
🧹 Nitpick comments (1)
apps/nextjs/pages-router/src/pages/server/index.tsx (1)
14-16: ⚡ Quick winUse
@ts-expect-errorinstead of@ts-ignorefor this temporary typing workaround.
@ts-ignorecan hide unrelated type errors on the same line;@ts-expect-errorpreserves the workaround but fails once the underlying issue is fixed.🔧 Suggested change
- // `@todo`: Fix excessively deep type instantiation error in session typing - // `@ts-ignore` Type instantiation is excessively deep and possibly infinite. + // `@todo`: Fix excessively deep type instantiation error in session typing + // `@ts-expect-error` Type instantiation is excessively deep and possibly infinite. session: session.success ? session.session : null,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/nextjs/pages-router/src/pages/server/index.tsx` around lines 14 - 16, Replace the temporary TypeScript suppression on the session line by swapping the existing "`@ts-ignore`" for "`@ts-expect-error`" so the line with "session: session.success ? session.session : null" still bypasses the deep-instantiation error but will surface if the root typing gets fixed; keep the todo comment above for follow-up.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/next/src/lib/utils.ts`:
- Around line 1-7: isPagesRouter currently starts an async IIFE that imports
"next/headers" but does not await or return it, so the function returns true
before the import can reject; change isPagesRouter to await (or return) the
import Promise so the try/catch can catch failures. Specifically, update the
function isPagesRouter to perform await import("next/headers") (or return the
import Promise) inside the try block instead of launching an unawaited async
IIFE so rejected imports are handled and the function reliably returns
true/false.
In `@packages/next/src/pages/handler.ts`:
- Around line 34-35: Normalize req.headers before constructing Headers and
ensure no body is sent for HEAD requests: replace the inline new
Headers(req.headers as Record<string,string>) with a normalized headers object
that iterates req.headers (which may have string | string[] | undefined), skips
undefined values, and joins string[] values with commas so every value is a
string; and change the body expression from method !== "GET" && req.body ?
JSON.stringify(req.body) : undefined to exclude HEAD as well (e.g., method !==
"GET" && method !== "HEAD" && req.body ? JSON.stringify(req.body) : undefined)
so no body is included for HEAD requests. Reference: the new Headers(...)
construction and the body assignment using method and req.body.
- Around line 42-48: Replace the non-existent res.setHeaders(...) usage by
iterating response.headers and calling res.setHeader(name, value) for each
header (use the existing res variable), and stop assuming JSON-only bodies:
after copying headers, first handle no-body statuses (e.g., response.status ===
204 || response.status === 304) by returning res.status(response.status).end();
otherwise inspect response.headers.get('content-type') — if it startsWith
'application/json' await response.json() and return
res.status(response.status).json(data); else read the body as an
ArrayBuffer/Buffer and return res.status(response.status).send(buffer) while
preserving the content-type header so non-JSON bodies are forwarded correctly.
Ensure this replaces the current unconditional await response.json() call in the
handler.
---
Outside diff comments:
In `@apps/nextjs/pages-router/src/pages/client/index.tsx`:
- Around line 49-50: Update the demo description string that currently mentions
"`@aura-stack/react`" to the correct package name "`@aura-stack/next/client`" so the
client demo text in pages/client/index.tsx (the line containing the literal
"Official Next.js demo to showcase `@aura-stack/react` authentication library with
Client Side Rendering (CSR), for Server-Side Rendering (SSR) visit") reflects
the current package; simply replace the package name in that string to
"`@aura-stack/next/client`".
---
Nitpick comments:
In `@apps/nextjs/pages-router/src/pages/server/index.tsx`:
- Around line 14-16: Replace the temporary TypeScript suppression on the session
line by swapping the existing "`@ts-ignore`" for "`@ts-expect-error`" so the line
with "session: session.success ? session.session : null" still bypasses the
deep-instantiation error but will surface if the root typing gets fixed; keep
the todo comment above for follow-up.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 81025067-2b73-4622-8d41-0bff315308ba
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (17)
apps/nextjs/pages-router/package.jsonapps/nextjs/pages-router/src/components/header.tsxapps/nextjs/pages-router/src/contexts/auth.tsxapps/nextjs/pages-router/src/lib/auth-client.tsapps/nextjs/pages-router/src/lib/auth.tsapps/nextjs/pages-router/src/pages/api/auth/[...aura].tsapps/nextjs/pages-router/src/pages/client/index.tsxapps/nextjs/pages-router/src/pages/server/index.tsxpackages/next/CHANGELOG.mdpackages/next/deno.jsonpackages/next/package.jsonpackages/next/src/createAuth.tspackages/next/src/lib/utils.tspackages/next/src/pages/createAuth.tspackages/next/src/pages/handler.tspackages/next/src/pages/index.tspackages/next/tsdown.config.ts
/pages module
Description
This pull request introduces a dedicated
/pagesentry module in@aura-stack/nextto provide first-class support for the Next.js Pages Router.With this addition, the package now supports both routing strategies:
Request,Response,Headers, etc.)IncomingMessage,ServerResponse)The new
/pagesentry module exposes utilities specifically designed for the Pages Router runtime and request lifecycle.Architecture Decision
The decision to introduce a dedicated
/pagesentry module was primarily driven by two architectural differences between the App Router and Pages Router.1. Different Request and Runtime Models
The App Router and Pages Router manage request data differently.
The App Router supports:
next/headersThis makes it possible for the package to provide an
apiobject with built-in request context handling and automatic session management.In contrast, the Pages Router requires request data to be passed manually through APIs such as:
getServerSidePropsBecause of this difference, the App Router and Pages Router cannot share the same internal request abstraction cleanly.
Packages such as:
@aura-stack/next@aura-stack/react-router@aura-stack/tanstack-startexpose both:
apicorewhere:
apiprovides framework-aware utilities with built-in request handlingcoreexposes the low-level utilities from@aura-stack/authWithout a dedicated Pages Router entry module, Pages Router users would need to rely on
createAuth.core.api, while App Router users would usecreateAuth.api.This creates unnecessary inconsistency and increases developer friction.
To solve this, a dedicated
/pagesmodule was introduced so Pages Router users can use a router-specificcreateAuthimplementation with the same high-level API experience.2.
next/headersIs Not Supported in Pages RouterThe built-in App Router implementation relies on the
next/headersmodule to access:However,
next/headersis not supported in the Pages Router runtime.Because of this limitation, the existing App Router implementation cannot be reused safely inside Pages Router environments.
Note
An alternative workaround was explored internally, but it introduced unnecessary complexity and did not align with the intended developer experience for the package.
Key Changes
/pagesentry module for Pages Router supportcreateAuthimplementation for Pages RoutertoHandlerhelper for handlingIncomingMessageandServerResponseUsage