I got tired of rewriting auth for every Next.js project, so I made a CLI that drops it into your repo as plain files.

[u/ChoiceConstruction80]

Every Next.js project I start needs the same auth: signup, login, sessions that survive a refresh, verify email, reset password. I kept rewriting it, so I turned it into a CLI.

npx nextauthforge init --dry-run   # shows what it would do, writes nothing
npx nextauthforge init

It copies plain source files into your repo. There's no auth library to depend on, so you can read and change everything. It also creates .env.local with a generated secret and patches your layout.

The part I'd like you to attack: sessions are a 15-minute access JWT plus a rotating refresh token. A replayed old token revokes the whole token family, and a 10-second grace window keeps two tabs refreshing at once from logging you out. Rotation is a single conditional DB update, and the same code runs on MongoDB and on PostgreSQL (Prisma 7).

Also included: email verification, forgot/reset password, change password, log out everywhere. Email goes through SMTP, Resend or a dev-only console adapter. There's optional Tailwind UI (auth pages, landing page, dashboard).

Safe to try on a real project: it never overwrites a file silently, --force writes a .bak first, and running it twice changes nothing.

Known limitations, so you don't have to find them yourself: the rate limiter is in memory (per instance), the access token stays valid up to 15 min after logout, signup reveals whether an email exists, and the UI needs Tailwind. The full list is in the README.

What I'd love from testers:

• Try it on a fresh create-next-app, then tell me anything confusing or broken (OS, Next version, DB).
• macOS/Linux, pnpm/yarn/bun and Firefox/Safari especially. I only tested on Windows 10 with Chromium.
• Look at the refresh-rotation code and tell me if you see a hole.

GitHub: https://github.com/Gauravkumar512/nextauthforge
npm: https://www.npmjs.com/package/nextauthforge

[u/zomerbk]

One refresh race worth testing: have two tabs refresh with the same token, then delay one response so its Set-Cookie arrives last. If that response writes a stale token, the next refresh could log the user out despite the conditional DB update. The 10-second grace window may hide the race at first, so I’d check what happens after it expires.