SQL and Seed into App

Dockerfile

@@ -67,16 +67,17 @@ COPY scripts ./scripts
 COPY src/lib/db-adapter.ts ./src/lib/db-adapter.ts
 COPY src/lib/password-breach-check.ts ./src/lib/password-breach-check.ts
 COPY --from=builder /app/src/generated ./src/generated
-# Eigener node_modules-Baum nur fuer Migrationen/Seed (prisma-CLI/tsx),
+# Migrations-/Seed-Pakete (prisma-CLI/tsx/dotenv) DIREKT ins selbe
-# getrennt vom node_modules des Next.js-Standalone-Outputs oben (das ist
+# node_modules wie der Next.js-Standalone-Output kopieren (ueberlagert dort
-# eine von Next.js kopierte, nicht pnpm-verwaltete Teilmenge — "pnpm add"
+# nur exakt dieselben Paketversionen, die builder bereits fuer next/react
-# wuerde dort kollidieren). PATH macht "prisma"/"tsx" ausfuehrbar,
+# aufgeloest hat) statt in einen separaten Baum + PATH/NODE_PATH-Trick: der
-# NODE_PATH ist ein Fallback fuer Node-Modulaufloesung, falls tsx beim
+# generierte Prisma-Client + tsx nutzen Node's ESM-Modulaufloesung, die
-# Ausfuehren von prisma/seed.ts ein Paket braucht, das der Next.js-Tracer
+# NODE_PATH schlicht ignoriert (nur ein CommonJS-"require()"-Feature) —
-# nicht schon ins Standalone-node_modules uebernommen hat.
+# fuehrte zu "Cannot find package '@prisma/client'" beim Seed-Lauf. Die
-COPY --chown=nextjs:nodejs --from=migrator /app/node_modules ./migrate-tools/node_modules
+# normale node_modules-Huelle nach oben (von jeder Datei unter /app/ aus)
-ENV PATH="/app/migrate-tools/node_modules/.bin:${PATH}"
+# funktioniert dagegen fuer beide Modulsysteme zuverlaessig.
-ENV NODE_PATH="/app/migrate-tools/node_modules"
+COPY --chown=nextjs:nodejs --from=migrator /app/node_modules ./node_modules
+ENV PATH="/app/node_modules/.bin:${PATH}"
 
 USER nextjs
 EXPOSE 3000