feat: migrate from NextAuth.js v4 to Auth.js v5 #988
Conversation
- Update next-auth to v5 beta and @auth/prisma-adapter - Refactor auth configuration to use new NextAuth() API - Export handlers, auth, signIn, signOut from auth module - Simplify API route handler to use exported handlers - Update session utility to use auth() function - Modernize middleware to use auth wrapper - Update auth hooks to use next/navigation (App Router) - Define SignInErrorTypes locally (removed internal import) - Fix import ordering and prettier warnings BREAKING CHANGE: Auth.js v5 uses different cookie names (authjs.* instead of next-auth.*)
📝 WalkthroughWalkthroughThis PR migrates authentication from NextAuth v4 to Auth.js/NextAuth v5: dependency updates, adapter rename, centralizing auth handlers, replacing getServerSession with auth(), updating middleware and client hooks to status-based flows, and adjusting types and error typings. Changes
Sequence Diagram(s)sequenceDiagram
participant Browser
participant AuthRoute as /api/auth/[...nextauth]
participant AuthLib as auth handlers (src/lib/auth)
participant Provider as OAuth Provider (GitHub/Google)
participant DB as Prisma Adapter
Browser->>AuthRoute: POST /api/auth/callback (oauth)
AuthRoute->>AuthLib: delegate to POST handler
AuthLib->>Provider: exchange code -> profile
AuthLib->>DB: upsert user/session via `@auth/prisma-adapter`
DB-->>AuthLib: user/session persisted
AuthLib-->>AuthRoute: set session cookie / response
AuthRoute-->>Browser: redirect to app
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI Agents
In @package.json:
- Line 69: Replace the beta v5 dependency entry "next-auth": "5.0.0-beta.30" in
package.json with the stable v4 line (e.g., "next-auth": "4.24.x" or a specific
4.24.y like "4.24.2"), then update your lockfile and reinstall (npm/yarn/pnpm)
to ensure the stable package is used; also scan for and revert any v5-specific
API usage introduced in the codebase (handlers/middleware that rely on v5
async-only behavior) so the app remains compatible with Next-Auth v4.
- Line 35: The package entry "@auth/prisma-adapter": "^2.11.1" may be
incompatible with your installed Prisma client version; verify the Prisma client
package (prisma and @prisma/client) versions against the adapter's supported
versions in the adapter's README/issues and pin or bump the adapter or Prisma
packages to matching compatible versions (or use a specific resolved range
instead of a caret) in package.json, then reinstall and run type/runtime tests
to confirm the mismatch is resolved.
In @src/lib/auth.ts:
- Line 19: The current export destructuring (export const { handlers, auth,
signIn, signOut } = NextAuth({ ... })) relies on synchronous NextAuth/next-auth
v5 behavior which is incompatible with Next.js 15 async route APIs; either
pin/rollback to the stable next-auth v4 release or migrate to a v5-compatible
async pattern. Fix by updating package.json to a supported stable next-auth
version (e.g., 4.x) or, if staying on next-auth v5, change the usage of
NextAuth/NextAuth(...) so you do not destructure synchronously — convert the
export to async-compatible handlers (await any factory that returns handlers)
and update exports for handlers, auth, signIn, signOut to be produced by an
async initializer invoked inside the route or middleware where
headers()/cookies() can be awaited. Ensure references to NextAuth, handlers,
auth, signIn, and signOut are updated accordingly.
In @src/types/next-auth.d.ts:
- Line 1: Update the type augmentation to use Auth.js v5's recommended
intersection pattern: import DefaultSession from "next-auth", then modify the
Session interface (and any other session declarations) so user is declared as
the custom fields (id: string, username?: string | null, admin?: boolean | null)
intersected with DefaultSession["user"] (i.e., user: { id: string; username?:
string | null; admin?: boolean | null } & DefaultSession["user"]); remove any
manual re-declaration of default name/email/image so default fields are
inherited.
🧹 Nitpick comments (1)
src/lib/auth.ts (1)
54-63: Remove unnecessary type assertions in session callback.The Prisma schema includes both
usernameandadminfields in the User model, and next-auth.d.ts properly extends both the Session.user and User interfaces to include these fields. The type assertions are redundant:username: (user as { username?: string }).username, admin: (user as { admin?: boolean }).adminCan be simplified to:
username: user.username, admin: user.adminSince the types are already properly defined through module augmentation, the explicit type assertions suggest the code wasn't leveraging the type definitions that are already in place.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (9)
package.jsonsrc/app/api/auth/[...nextauth]/route.tssrc/app/login/ErrorMessage.tsxsrc/lib/auth.tssrc/lib/session.tssrc/lib/useRequireAdmin.tssrc/lib/useRequireAuth.tssrc/middleware.tssrc/types/next-auth.d.ts
🔇 Additional comments (10)
src/lib/useRequireAuth.ts (2)
3-3: LGTM: Correct migration to App Router patterns.The switch to
next/navigationand extraction ofstatusfromuseSession()align with App Router best practices and Auth.js v5 patterns.Also applies to: 8-8
11-16: LGTM: Status-based redirect is more reliable.Using
status === 'unauthenticated'is the recommended pattern for Auth.js v5, as it avoids race conditions that can occur when checking the session object directly during hydration.src/app/login/ErrorMessage.tsx (1)
5-16: LGTM: Correct approach for v5 compatibility.Defining
SignInErrorTypeslocally is necessary because Auth.js v5 no longer exports this type. The enumerated error codes match the standard NextAuth error types and maintain backward compatibility.src/lib/useRequireAdmin.ts (2)
3-3: LGTM: Consistent App Router migration.The changes mirror the pattern in
useRequireAuth.ts, correctly adoptingnext/navigationand status-based session tracking.Also applies to: 8-8
12-19: LGTM: Correct two-stage authorization logic.The conditional structure properly handles:
- Unauthenticated users → login page
- Authenticated non-admins → home page
By checking
status === 'authenticated'before accessingsession?.user.admin, the code avoids race conditions during the loading state. The dependency array correctly includes bothstatusandsession.src/lib/session.ts (1)
1-7: LGTM! Correct migration to Auth.js v5.The update to use the centralized
auth()function instead ofgetServerSession(authOptions)follows the correct Auth.js v5 pattern. The function properly awaits the session and maintains the same public API surface.src/app/api/auth/[...nextauth]/route.ts (1)
1-3: LGTM! Correct migration to centralized handlers.The migration to export
GETandPOSTfrom the centralizedhandlersobject is the correct Auth.js v5 pattern. This simplifies the route file and consolidates auth configuration insrc/lib/auth.ts.src/lib/auth.ts (2)
1-6: LGTM! Correct Auth.js v5 imports.The import changes are correct for the v5 migration:
PrismaAdapterfrom@auth/prisma-adapter(updated package)NextAuthas default import (new v5 pattern)GitHuband
19-48: LGTM! Correct Auth.js v5 export pattern and provider configuration.The new export pattern correctly destructures
handlers,auth,signIn, andsignOutfromNextAuth(). The provider configurations for GitHub and Google are properly updated with:
- Capital case naming (
GitHub,- Correct profile mapping that includes the custom
usernamefield- Proper environment variable usage
src/middleware.ts (1)
3-10: LGTM! Correct migration to Auth.js v5 middleware pattern.The migration to the
authwrapper is correct for v5. The new pattern:
- Wraps the middleware function with
auth(req => { ... })- Uses
req.authto check authentication status (set by the wrapper)- Simplifies logic by removing manual cookie parsing
The
req.authproperty is properly typed through NextAuth's exportedauthwrapper function, which automatically provides middleware request typing. Custom type augmentation forSessionandUseris correctly configured insrc/types/next-auth.d.tsfor application-specific user data.
| "test:e2e": "playwright test" | ||
| }, | ||
| "dependencies": { | ||
| "@auth/prisma-adapter": "^2.11.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@auth/prisma-adapter 2.11.1 compatibility next-auth 5.0.0-beta.30
💡 Result:
Short answer: Yes — @auth/[email protected] is the Auth.js/NextAuth v5 adapter package and is intended to be used with NextAuth/Auth.js v5 (including 5.0.0-beta.*). [1][2]
Notes:
- The v5 migration docs explicitly instruct moving to the @auth/* adapter scope (e.g. @auth/prisma-adapter) for v5. [1]
- Make sure your Prisma client version is compatible with the adapter — there have been reported issues when adapter and Prisma client versions mismatch (example: older adapter vs Prisma 6.x). If you see runtime/type errors, check the adapter GitHub/npm docs and any open issues for your exact Prisma + adapter versions. [2][3]
Sources:
[1] Auth.js / NextAuth v5 migration docs (adapters → use @auth/prisma-adapter). (authjs.cn)
[2] @auth/prisma-adapter package / registry (v2.11.1 listed). (classic.yarnpkg.com)
[3] Example issue showing adapter/Prisma client incompatibility reports. (github.com)
Citations:
- 1: https://www.authjs.cn/getting-started/migrating-to-v5?utm_source=openai
- 2: https://classic.yarnpkg.com/en/package/%40auth/prisma-adapter?utm_source=openai
- 3: @auth/[email protected] does not work with prisma/[email protected] nextauthjs/next-auth#12899
Verify Prisma client version compatibility with the adapter.
@auth/prisma-adapter@^2.11.1 is confirmed compatible with [email protected] for Auth.js v5. However, ensure your Prisma client version is compatible with this adapter version—mismatches between adapter and Prisma client versions (e.g., older adapter with Prisma 6.x) can cause runtime or type errors. Check the adapter's GitHub/npm documentation and any reported issues for your specific Prisma + adapter version combination.
🤖 Prompt for AI Agents
In @package.json at line 35, The package entry "@auth/prisma-adapter": "^2.11.1"
may be incompatible with your installed Prisma client version; verify the Prisma
client package (prisma and @prisma/client) versions against the adapter's
supported versions in the adapter's README/issues and pin or bump the adapter or
Prisma packages to matching compatible versions (or use a specific resolved
range instead of a caret) in package.json, then reinstall and run type/runtime
tests to confirm the mismatch is resolved.
| "motion": "12.23.24", | ||
| "next": "15.5.9", | ||
| "next-auth": "4.24.11", | ||
| "next-auth": "5.0.0-beta.30", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
next-auth 5.0 current stable release status npm
💡 Result:
As of Jan 6, 2026: next-auth v5 is still published as beta on npm (5.0.0‑beta.x); the latest stable release series on npm remains the 4.24.x line. [1][2][3]
Sources:
- npm package page for next-auth v5.0.0‑beta.27. [1]
- Release tracking showing 5.0.0‑beta.* releases and 4.24.x as the stable line. [2]
- Snyk/npm package summary (shows latest stable as 4.24.x). [3]
🌐 Web query:
next-auth 5.0.0-beta.30 known issues production
💡 Result:
Known/observed production issues for next-auth 5.0.0-beta.30 (summary):
- "MissingSecret" build error reported when using v5 betas (affects builds since beta.16). [1]
- Session data inconsistencies on initial login reported in v5 beta. [2]
- Compatibility problems with Next.js 15’s new async-only APIs (synchronous use of headers()) causing runtime errors/warnings. [3]
- Problems when running behind a basePath / reverse proxy (redirects, unknown action / callbacks failing) reported for v5 in production setups. [4]
- Snyk notes v5.0.0-beta.30 as the first non-vulnerable release for a specific email-parsing vulnerability present in earlier betas; still treat betas as unstable for production. [5]
Sources:
[1] GitHub issue "MissingSecret error during Next build" (nextauthjs/next-auth).
[2] GitHub issue "Session Data Inconsistency on Initial Login in NextAuth v5 Beta" (nextauthjs/next-auth).
[3] GitHub issue "Error on Next.js 15 about synchronous usage of headers()" (nextauthjs/next-auth).
[4] Reddit / community threads discussing basePath / proxy production issues with Auth.js (v5).
[5] Snyk package page for next-auth 5.0.0-beta.30.
If you want, I can open those issues and extract exact reports / timestamps or help you troubleshoot a specific production error you’re seeing.
🌐 Web query:
Auth.js next-auth version 5 released stable 2025 2026
💡 Result:
No — Auth.js / NextAuth v5 was still beta as of January 6, 2026 (no stable v5 release). Official docs and repo still reference v5 as a beta/“next-auth@beta” release and migration guidance, and there are open issues asking for clarity on v5’s beta status. [1][2][3]
Sources:
- Auth.js v5 migration docs (shows install via next-auth@beta). [1]
- Auth.js / Next.js reference page noting deprecations and v5 replacement. [2]
- next-auth GitHub issues/discussions about v5/beta status and migration. [3]
Remove next-auth beta version; use stable v4.24.x for production.
Next-auth v5 (5.0.0-beta.30) remains in beta as of January 2026, with the stable release series still being 4.24.x. Production deployments with v5 beta risk multiple documented issues:
- MissingSecret build errors
- Session data inconsistencies on initial login
- Incompatibility with Next.js 15's async-only APIs (e.g., synchronous
headers()calls) - basePath and reverse proxy failures (redirects, callback handling)
Use the stable 4.24.x line unless explicitly evaluating v5 as a pre-release.
🤖 Prompt for AI Agents
In @package.json at line 69, Replace the beta v5 dependency entry "next-auth":
"5.0.0-beta.30" in package.json with the stable v4 line (e.g., "next-auth":
"4.24.x" or a specific 4.24.y like "4.24.2"), then update your lockfile and
reinstall (npm/yarn/pnpm) to ensure the stable package is used; also scan for
and revert any v5-specific API usage introduced in the codebase
(handlers/middleware that rely on v5 async-only behavior) so the app remains
compatible with Next-Auth v4.
| } | ||
|
|
||
| export const authOptions: NextAuthOptions = { | ||
| export const { handlers, auth, signIn, signOut } = NextAuth({ |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Auth.js v5 release status production ready January 2026
💡 Result:
Short answer: No — Auth.js v5 was still released as beta and not marked a stable production release as of January 6, 2026. The project docs and community threads show v5 distributed under beta tags and many users running it in production by choice, but the repository/issues and community guidance still treat v5 as beta/unstable. [1][2][3]
Sources:
- Official site / docs (migration to v5 / beta guidance). [1]
- Community discussion / forum threads noting v5 remains beta and mixed production use. [2]
- GitHub issues showing ongoing v5 beta bug reports and development activity. [3]
🌐 Web query:
next-auth 5.0.0-beta.30 breaking changes Next.js 15 compatibility
💡 Result:
Short summary — yes, Next.js 15 introduced breaking changes that affect next-auth (Auth.js). Key points and what to do:
- What broke
- Next.js 15 made dynamic route APIs (headers(), cookies(), etc.) asynchronous. Auth.js / next-auth previously accessed them synchronously, causing runtime/type errors in Next 15.
Address next-auth v5 beta status and Next.js 15 async API incompatibility.
[email protected] remains beta software as of January 2026 and is not marked as a stable production release. More critically, Next.js 15 introduced breaking changes—the dynamic route APIs (headers(), cookies(), etc.) are now asynchronous, while Auth.js v5 accesses them synchronously, causing runtime and type errors. Verify that your setup properly handles this async/await requirement before deploying to production.
🤖 Prompt for AI Agents
In @src/lib/auth.ts at line 19, The current export destructuring (export const {
handlers, auth, signIn, signOut } = NextAuth({ ... })) relies on synchronous
NextAuth/next-auth v5 behavior which is incompatible with Next.js 15 async route
APIs; either pin/rollback to the stable next-auth v4 release or migrate to a
v5-compatible async pattern. Fix by updating package.json to a supported stable
next-auth version (e.g., 4.x) or, if staying on next-auth v5, change the usage
of NextAuth/NextAuth(...) so you do not destructure synchronously — convert the
export to async-compatible handlers (await any factory that returns handlers)
and update exports for handlers, auth, signIn, signOut to be produced by an
async initializer invoked inside the route or middleware where
headers()/cookies() can be awaited. Ensure references to NextAuth, handlers,
auth, signIn, and signOut are updated accordingly.
| @@ -1,4 +1,4 @@ | |||
| import { DefaultSession } from 'next-auth' | |||
| import 'next-auth' | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Auth.js v5 next-auth TypeScript session type augmentation pattern
💡 Result:
Short pattern (Auth.js v5 / next-auth) — create a global type augmentation file and merge your custom fields with the defaults.
-
Create a file (e.g. types/next-auth.d.ts) that is included by TS (or add types/ to tsconfig typeRoots).
-
Example contents:
import { DefaultSession } from "next-auth"
import { JWT } from "next-auth/jwt"
declare module "next-auth" {
interface Session {
user: {
id: string
role?: "admin" | "user"
} & DefaultSession["user"]
}
// optional: augment other interfaces if needed
interface User {
id: string
role?: "admin" | "user"
}
}
declare module "next-auth/jwt" {
interface JWT {
id?: string
role?: "admin" | "user"
}
}
- Use the session callback to populate fields (server-side) so the runtime matches the types:
callbacks: {
session({ session, user }) {
if (session.user) session.user.id = user.id
return session
}
}
Notes:
- Always merge with DefaultSession["user"] if you want to keep default fields (name, email, image). [1][2]
- Ensure the types file is picked up by tsconfig (or placed under an included folder) and restart TS server if needed. [1][3]
Sources: Auth.js / NextAuth TypeScript docs. [1] https://authjs.dev/getting-started/typescript [2] https://next-auth.js.org/getting-started/typescript [3] create-t3-app / NextAuth usage.
🏁 Script executed:
cat -n src/types/next-auth.d.tsRepository: programming-in-th/programming.in.th
Length of output: 674
Use the recommended & DefaultSession["user"] pattern for Auth.js v5 type augmentation.
The current session type manually re-declares default fields (name, email, image) instead of merging with DefaultSession["user"]. Auth.js v5 documentation explicitly recommends the intersection pattern to inherit default fields and ensure future compatibility:
interface Session {
user: {
id: string
username?: string | null
admin?: boolean | null
} & DefaultSession["user"]
}This also requires importing DefaultSession from "next-auth".
Also applies to: 12-12
🤖 Prompt for AI Agents
In @src/types/next-auth.d.ts at line 1, Update the type augmentation to use
Auth.js v5's recommended intersection pattern: import DefaultSession from
"next-auth", then modify the Session interface (and any other session
declarations) so user is declared as the custom fields (id: string, username?:
string | null, admin?: boolean | null) intersected with DefaultSession["user"]
(i.e., user: { id: string; username?: string | null; admin?: boolean | null } &
DefaultSession["user"]); remove any manual re-declaration of default
name/email/image so default fields are inherited.
This commit fixes critical issues identified in PR #988 code review: 1. **Add AUTH_SECRET environment variable** - Added AUTH_SECRET to .env.example with generation instructions - Added AUTH_URL to replace NEXTAUTH_URL for v5 - Updated auth.ts to check for AUTH_SECRET in environment validation 2. **Fix type safety issues in session callback** - Removed unsafe type assertions for username and admin fields - Type definitions in next-auth.d.ts now properly recognized - Session callback now uses proper typed User interface 3. **Improve authentication hook loading states** - Updated useRequireAuth to handle 'loading' status explicitly - Updated useRequireAdmin to handle 'loading' status explicitly - Both hooks now return null during loading to prevent content flash - Prevents redirect flashing during authentication checks 4. **Add comprehensive migration documentation** - Created MIGRATION_V5.md with breaking changes documentation - Documented forced user logout due to cookie name changes - Added deployment checklist and testing guide - Included rollback plan and support information All changes verified with: - ✅ pnpm check-types (TypeScript passes) - ✅ pnpm lint (ESLint passes with pre-existing warnings) - ✅ pnpm test (10/10 tests pass) Addresses code review feedback for PR #988.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.claude/skills/api-development/SKILL.md:
- Around line 7-35: Update the docs example to use Next.js App Router handlers
and Zod validation: replace the Elysia route snippets with a Next.js route
handler (e.g., src/app/api/tasks/route.ts) that calls TaskSchema.parse(await
req.json()) for POST bodies and parses route/query values as needed, and on
validation failure return the existing badRequest() utility with a 400 response;
mention using TaskSchema.parse in the handler and show using badRequest() for
errors so the example matches the codebase conventions.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
.claude/agents/code-reviewer.md.claude/agents/security-reviewer.md.claude/commands/perf.md.claude/commands/review.md.claude/commands/verify.md.claude/settings.json.claude/skills/api-development/SKILL.md.claude/skills/component-development/SKILL.md.claude/skills/database-changes/SKILL.md.env.exampleCLAUDE.mdMIGRATION_V5.mdsrc/lib/auth.tssrc/lib/useRequireAdmin.tssrc/lib/useRequireAuth.ts
✅ Files skipped from review due to trivial changes (4)
- .claude/skills/component-development/SKILL.md
- .claude/commands/perf.md
- .claude/commands/review.md
- MIGRATION_V5.md
🚧 Files skipped from review as they are similar to previous changes (1)
- src/lib/useRequireAdmin.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{tsx,ts}@(!(\.[a-z]+))
📄 CodeRabbit inference engine (CLAUDE.md)
Use Server Components by default in Next.js 15 with React 19, only using Client Components when needed for forms, useState, useEffect, or browser APIs
Files:
src/lib/useRequireAuth.tssrc/lib/auth.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx}: Always use selective Prisma fields withselectclause, never fetch all fields
Always import Prisma from '@/lib/prisma' (singleton), never import from '@prisma/client' directly
Implement ISR (Incremental Static Regeneration) and SWR caching strategies for performance optimization
Use getServerUser() from '@/lib/session' for server-side authentication
Files:
src/lib/useRequireAuth.tssrc/lib/auth.ts
🧠 Learnings (9)
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to **/*.{ts,tsx} : Always import Prisma from '@/lib/prisma' (singleton), never import from 'prisma/client' directly
Applied to files:
.claude/skills/database-changes/SKILL.mdCLAUDE.mdsrc/lib/auth.ts
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to **/*.{ts,tsx} : Always use selective Prisma fields with `select` clause, never fetch all fields
Applied to files:
.claude/skills/database-changes/SKILL.md
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to app/**/*route.{ts,tsx} : Always validate API route inputs with Zod, returning 400 status code with error message for invalid input
Applied to files:
.claude/skills/api-development/SKILL.md
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to app/**/*.{ts,tsx} : Check user.admin property to gate admin-only routes
Applied to files:
.claude/skills/api-development/SKILL.md
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Run 'pnpm check-types && pnpm lint && pnpm test' before commits to prevent regressions
Applied to files:
.claude/commands/verify.md
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to **/*.{ts,tsx} : Use getServerUser() from '@/lib/session' for server-side authentication
Applied to files:
src/lib/useRequireAuth.ts
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to **/*.{tsx,ts}@(!(\.[a-z]+)) : Use Server Components by default in Next.js 15 with React 19, only using Client Components when needed for forms, useState, useEffect, or browser APIs
Applied to files:
CLAUDE.md
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Applies to **/*.{ts,tsx} : Implement ISR (Incremental Static Regeneration) and SWR caching strategies for performance optimization
Applied to files:
CLAUDE.md
📚 Learning: 2026-01-09T09:13:34.812Z
Learnt from: CR
Repo: programming-in-th/programming.in.th PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-09T09:13:34.812Z
Learning: Use strict TypeScript with full type safety across the codebase
Applied to files:
CLAUDE.md
🧬 Code graph analysis (2)
src/lib/useRequireAuth.ts (3)
src/middleware.ts (1)
middleware(4-11)src/components/RootLayout/Navbar/DesktopProfile.tsx (1)
data(13-92)src/components/RootLayout/Navbar/MobileProfile.tsx (1)
data(12-73)
src/lib/auth.ts (2)
src/types/next-auth.d.ts (2)
Session(4-13)User(15-22)src/app/user/page.tsx (1)
User(15-53)
🔇 Additional comments (11)
.claude/commands/verify.md (1)
1-11: LGTM!The verification workflow is clearly documented, properly sequenced, and aligns with the project's quality standards. This provides a good foundation for developers to validate changes before committing.
.claude/agents/code-reviewer.md (1)
17-21: Update key patterns to reflect Auth.js v5 auth() function.Line 19 references
getServerUser(), which is inconsistent with the Auth.js v5 migration. The agent should guide reviewers toward the newauth()function pattern for obtaining server-side sessions.🔄 Suggested update to key patterns
- **Auth**: `getServerUser()` from `@/lib/session`, check `user.admin` + **Auth**: Use `auth()` from Auth.js v5 for server-side sessions, check `user.admin` for admin routes⛔ Skipped due to learnings
Learnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{ts,tsx} : Use getServerUser() from '@/lib/session' for server-side authenticationLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{ts,tsx} : Always import Prisma from '@/lib/prisma' (singleton), never import from 'prisma/client' directlyLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{tsx,jsx,css} : Use Tailwind 'dark:' variants for dark mode stylingLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{ts,tsx} : Always use selective Prisma fields with `select` clause, never fetch all fieldsLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{tsx,ts}@(!(\.[a-z]+)) : Use Server Components by default in Next.js 15 with React 19, only using Client Components when needed for forms, useState, useEffect, or browser APIsLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to app/**/*route.{ts,tsx} : Always validate API route inputs with Zod, returning 400 status code with error message for invalid inputCLAUDE.md (1)
40-44: Update Gotchas section to reflect Auth.js v5 auth() pattern.Line 43 references
getServerUser()for server-side auth. This should be updated to align with the Auth.js v5 migration, whereauth()is the primary function for obtaining server-side session data.🔄 Suggested update to Gotchas section
- **Auth**: `getServerUser()` for server-side, check `user.admin` for admin routes + **Auth**: Use `auth()` function for server-side session, check `user.admin` for admin routes (Auth.js v5)⛔ Skipped due to learnings
Learnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{ts,tsx} : Use getServerUser() from '@/lib/session' for server-side authenticationLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{ts,tsx} : Always import Prisma from '@/lib/prisma' (singleton), never import from 'prisma/client' directlyLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to **/*.{ts,tsx} : Always use selective Prisma fields with `select` clause, never fetch all fieldsLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Use presigned S3 URLs only for file access and sanitize all file pathsLearnt from: CR Repo: programming-in-th/programming.in.th PR: 0 File: CLAUDE.md:0-0 Timestamp: 2026-01-09T09:13:34.812Z Learning: Applies to app/**/*.{ts,tsx} : Check user.admin property to gate admin-only routes.claude/settings.json (1)
1-43: LGTM! Well-structured Claude IDE configuration.The permissions are appropriately scoped to read-only and safe operations, and the hooks provide helpful reminders without making automated changes to the codebase.
.claude/skills/api-development/SKILL.md (1)
37-48: Admin authorization pattern aligns with coding guidelines.The admin check using
user.adminproperty correctly implements the authorization pattern for admin-only routes.Based on coding guidelines, this follows the learned pattern for gating admin routes.
.claude/skills/database-changes/SKILL.md (1)
1-35: LGTM! Database patterns align with coding guidelines.The documented patterns correctly enforce:
- Singleton Prisma import from
@/lib/prisma- Selective field selection with
selectclause- Pagination for list queries
- N+1 query prevention strategies
- Proper indexing guidance
Based on coding guidelines, these patterns match the learned requirements for Prisma usage.
.claude/agents/security-reviewer.md (2)
14-14: LGTM! Validation pattern follows best practices.The Zod
safeParse()pattern with 400 status code for invalid input aligns with the coding guidelines for API route validation.Based on coding guidelines, this matches the learned requirement for input validation.
Also applies to: 29-30
13-13: No changes needed. The documentation correctly referencesgetServerUser()from@/lib/session, which is properly defined as a wrapper around Auth.js v5'sauth()function. The documented pattern aligns with the actual implementation in the migrated codebase.Likely an incorrect or invalid review comment.
.env.example (1)
7-11: LGTM! Auth.js v5 environment variables properly documented.The new
AUTH_SECRETandAUTH_URLvariables are well-documented with:
- Clear generation instructions for the secret
- Explicit explanation of the v4 → v5 migration (NEXTAUTH_URL → AUTH_URL)
- Appropriate default value for local development
src/lib/useRequireAuth.ts (1)
1-26: LGTM! Clean migration to Auth.js v5 patterns.The migration from
next/routertonext/navigationaligns with Next.js 15, and the status-based authentication flow (loading→unauthenticated→ redirect) is the correct pattern for Auth.js v5. Returningnullduring loading prevents content flash, and the dependency array properly tracksstatusinstead ofsession.src/lib/auth.ts (1)
1-65: LGTM! Auth.js v5 migration implemented correctly.All migration steps are properly executed:
- Adapter updated to
@auth/prisma-adapter- Provider imports use new v5 names (
GitHub,AUTH_SECRETvalidation added- Export pattern follows v5 API (destructured
handlers,auth,signIn,signOut)- Prisma singleton imported from
@/lib/prismaas per coding guidelinesThe profile callbacks and session callback correctly map to the typed
UserandSessioninterfaces shown in the type definitions.
| API routes use [Elysia](https://elysiajs.com) with TypeBox validation: | ||
|
|
||
| ```typescript | ||
| import { Elysia, t } from 'elysia' | ||
| import { prisma } from '@/lib/prisma' | ||
|
|
||
| const app = new Elysia() | ||
| .get('/tasks/:id', async ({ params, query, status }) => { | ||
| const limit = query.limit ?? 10 | ||
| const task = await prisma.task.findUnique({ | ||
| where: { id: params.id }, | ||
| select: { id: true, title: true } | ||
| }) | ||
| if (!task) return status(404, { error: 'Not found' }) | ||
| return task | ||
| }, { | ||
| params: t.Object({ id: t.String() }), | ||
| query: t.Object({ limit: t.Optional(t.Numeric()) }) | ||
| }) | ||
| .post('/tasks', async ({ body, status }) => { | ||
| const task = await prisma.task.create({ data: body }) | ||
| return status(201, task) | ||
| }, { | ||
| body: t.Object({ | ||
| title: t.String({ minLength: 1 }), | ||
| fullScore: t.Number({ minimum: 0 }) | ||
| }) | ||
| }) | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if Elysia is used in the codebase
echo "=== Checking for Elysia usage ==="
rg -l "from 'elysia'" --type=ts --type=tsx 2>/dev/null | head -20
echo -e "\n=== Checking for Zod usage ==="
rg -l "from 'zod'" --type=ts --type=tsx 2>/dev/null | head -20
echo -e "\n=== Checking API route files ==="
fd "route\.(ts|tsx)$" src/app 2>/dev/null | head -20
echo -e "\n=== Checking package.json for dependencies ==="
cat package.json | jq '.dependencies, .devDependencies' 2>/dev/null | grep -E '"(elysia|zod)"' -A0
echo -e "\n=== Checking for Elysia in package.json ==="
grep -i "elysia" package.json || echo "No Elysia found in package.json"
echo -e "\n=== Checking for Zod in package.json ==="
grep -i "zod" package.json || echo "No Zod found in package.json"Repository: programming-in-th/programming.in.th
Length of output: 1097
🏁 Script executed:
#!/bin/bash
# Check a sample API route to see if it uses Zod validation
echo "=== Sample API route: src/app/api/tasks/route.ts ==="
cat -n src/app/api/tasks/route.ts | head -50
echo -e "\n=== Check for Zod usage in API routes ==="
rg "from 'zod'" src/app/api --type=ts -A2 -B2 | head -40Repository: programming-in-th/programming.in.th
Length of output: 2171
Replace Elysia/TypeBox examples with Next.js and Zod.
This documentation demonstrates Elysia with TypeBox validation, but the codebase uses Next.js App Router with Zod. The API routes (e.g., src/app/api/tasks/route.ts) parse input using Zod schemas (e.g., TaskSchema.parse(await req.json())) and return errors via a badRequest() utility. Update the examples to match the actual tech stack, showing how to validate route inputs with Zod and return a 400 status code for invalid input.
🤖 Prompt for AI Agents
In @.claude/skills/api-development/SKILL.md around lines 7 - 35, Update the docs
example to use Next.js App Router handlers and Zod validation: replace the
Elysia route snippets with a Next.js route handler (e.g.,
src/app/api/tasks/route.ts) that calls TaskSchema.parse(await req.json()) for
POST bodies and parses route/query values as needed, and on validation failure
return the existing badRequest() utility with a 400 response; mention using
TaskSchema.parse in the handler and show using badRequest() for errors so the
example matches the codebase conventions.
BREAKING CHANGE: Auth.js v5 uses different cookie names (authjs.* instead of next-auth.*)
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.