CodeVetter · Repo Unpack · Behavior traces
blitz-js/blitz
The investigation followed startup, browser login, subsequent session validation, password recovery, and application generation through their actual implementations. Startup includes code generation before spawning Next.js. Login crosses build-time resolver substitution, browser transport, middleware, database access, and cookie propagation. Persistence is revisited on later requests, while password reset and scaffolding have their own ordered side effects.
- Startup begins at bin/blitz → CLI main → commands.dev; main establishes NODE_ENV, loads environment configuration, and dispatches the command after handling common flags.
- dev command → next-commands.dev → normalize → codegenTasks → nextStartDev, unless a custom server exists, in which case startCustomServer is selected.
- codegenTasks patches Next client recovery handling, calls generateManifest, and may run Prisma generate; generateManifest writes JS and type files under the located node_modules/.blitz.
- nextStartDev detects a port, sets BLITZ_DEV_SERVER_ORIGIN, filters framework names from process arguments, and spawns the resolved Next executable with inherited stdio.
- Login submission follows LoginForm.onSubmit → loginMutation from useMutation → enhancedResolverRpcClient → fetch, with the imported login module replaced by loader-client in browser builds.
- The sample Pages login request follows api → handleRequestWithMiddleware → auth session middleware/getSession → rpcHandler → login resolver; its default resolver reads the user by email and calls session.$create.
- session.$create → createNewSession → storage.createSession persists the authenticated session and updates cookies; rpcHandler calls setSession before responding, and AuthClientPlugin converts the response signals into browser session updates.
- On a later authenticated request, getSession → getSessionKernel → parseSessionToken → storage.getSession checks version, persisted token hash, expiration, and CSRF; eligible non-GET requests can call refreshSession.
- Password recovery follows resolver.zod(ForgotPassword) → user lookup → token generation/hash → deletion of prior reset tokens → token.create → forgotPasswordMailer.send; the absent-user branch waits 750 ms and returns the same result.
- Password reset follows ResetPassword.parse → hash256/token.findFirst → token.delete → expiration check → SecurePassword.hash/user.update → session.deleteMany → login.
- Application creation follows newApp's interactive selections → AppGenerator.run → write/preCommit/conflict checking → postWrite; postWrite updates dependency versions, optionally installs packages, invokes onPostInstall, formats, and commits Git changes.