History

barsa 89b495db1a Update ESLint configuration, package dependencies, and improve Prisma integration

- Refactored ESLint configuration for better clarity and organization, including updates to TypeScript rules and Next.js app settings.
- Upgraded package dependencies, including Next.js to version 16.0.8 and Prisma to version 7.1.0, enhancing performance and compatibility.
- Modified Dockerfile for BFF to reflect updated Prisma version and optimize build settings.
- Improved Prisma service to utilize PostgreSQL connection pooling with the new PrismaPg adapter, ensuring better database management.
- Cleaned up TypeScript configuration files for consistency and updated module settings to align with ESNext standards.
- Adjusted pre-commit script to streamline security audits and removed unnecessary linting during development.

2025-12-10 13:59:41 +09:00

migrations

Remove cached profile fields migration and update CSRF middleware for new public auth endpoints

2025-11-21 17:12:34 +09:00

prisma.config.ts

Update ESLint configuration, package dependencies, and improve Prisma integration

2025-12-10 13:59:41 +09:00

README.md

Enhance development scripts and update package dependencies

2025-12-02 18:56:38 +09:00

schema.prisma

Update ESLint configuration, package dependencies, and improve Prisma integration

2025-12-10 13:59:41 +09:00

README.md

Prisma Configuration

Overview

This directory contains the Prisma schema and migrations for the BFF application.

Important: Docker Build Behavior

The Problem with Monorepos

Prisma embeds the schema path into the generated client. In a monorepo, this path is relative to the workspace root (e.g., apps/bff/prisma/schema.prisma). However, in production Docker containers, the directory structure is flattened by pnpm deploy, placing the schema at prisma/schema.prisma.

How We Solve This

In the Dockerfile, we regenerate the Prisma client inside the production directory layout so the embedded path is /app/prisma/schema.prisma:

WORKDIR /app
RUN npx prisma@6.16.0 generate --schema=prisma/schema.prisma

This ensures the embedded schema path matches the production layout.

Directory Structure

Development (Monorepo)

/project-root/
├── apps/bff/
│   ├── prisma/
│   │   ├── schema.prisma    ← Schema here
│   │   └── migrations/
│   └── src/
└── packages/

Production (Docker Container)

/app/
├── prisma/
│   ├── schema.prisma        ← Schema here (flattened)
│   └── migrations/
├── dist/
└── node_modules/
    └── .prisma/client/      ← Generated client

Commands

Command	Description
`pnpm db:generate`	Regenerate Prisma client (`--schema=prisma/schema.prisma`)
`pnpm db:migrate`	Run migrations (dev) with explicit schema path
`pnpm db:studio`	Open Prisma Studio with explicit schema path
`pnpm db:reset`	Reset database with explicit schema path

Binary Targets

The schema includes binary targets for both development and production:

binaryTargets = ["native", "linux-musl-openssl-3.0.x"]

native: For local development (macOS, Windows, Linux)
linux-musl-openssl-3.0.x: For Alpine Linux in Docker

Troubleshooting

"Could not load schema from path" Error

This error occurs when the Prisma client was generated with a different schema path than what exists in the current environment.

Solution: Ensure the Dockerfile regenerates the Prisma client from the production-like directory structure (see above).

Client Not Found

If you see "Prisma Client not found" errors:

Run pnpm db:generate locally
For Docker, ensure the Dockerfile includes the prisma generate step

Migration Strategy

Create migrations locally: pnpm db:migrate
Commit the migration files
In production, the entrypoint runs: prisma migrate deploy --schema=/app/prisma/schema.prisma