SeeRepo con Next.js

SeeRepo reconoce una app de Next.js por el paquete next de su package.json. Funciona con el App Router y con el Pages Router, y con monorepos: cada paquete se lee con su propio framework.

Lo que lee SeeRepo

App Router

• Cada archivo page es una pantalla.
• Cada archivo route es una acción. Las rutas bajo api/cron/ son cosas que corren solas.
• Los webhooks son puertas de API para máquinas: SeeRepo los reconoce por su ruta o por la comprobación de firma que llevan dentro (constructEvent de Stripe, Svix, el HMAC de Shopify). También lo son .well-known, una ruta api/mcp, el sitemap, robots y las imágenes Open Graph.
• Un archivo que empieza con 'use server' es una acción: tus server actions.
• middleware e instrumentation también son puertas, y los archivos layout, loading y error son archivos especiales del router.

Pages Router

• Los archivos de pages/ son pantallas, y los de pages/api/, acciones.
• _app y _document son puertas.

Quién entra

Una pantalla que pide sesión es para Personas con cuenta; una que no, para Visitantes. Los webhooks vienen de Máquinas.

Un ejemplo de nuestro banco de pruebas

vercel/nextjs-subscription-payments, un starter de Next.js App Router con Supabase y Stripe, leído en un commit fijo:

• 4 pantallas, 4 acciones y 1 puerta de API (app/api/webhooks/route.ts, el webhook de Stripe)
• 5 modelos de datos de su migración de Supabase: customers, prices, products, subscriptions y users
• Servicios encontrados con su prueba: Supabase (8 archivos) y Stripe (7 archivos)
• 3 pantallas para visitantes y 1 que pide sesión (app/account/page.tsx)

Bueno saber

• Los modelos de datos se leen de Prisma, de las migraciones de Supabase y de Mongoose. Los modelos de Drizzle aún no se leen: en nuestro banco, nextjs/saas-starter usa Drizzle y su mapa no muestra modelos de datos.
• Los servicios salen de tres señales: los paquetes que importas, los nombres de tus variables de entorno y las URLs de tu código.
• Ver también Supabase, Prisma y Mongoose.