Claude
0a15275d1b
Le conteneur démarrait puis s'arrêtait sur « Cannot find module '@prisma/config' ». Le Dockerfile prélevait à la main quelques répertoires de node_modules — `prisma`, `.bin/prisma`, `@prisma` — en supposant une disposition plate. pnpm range les dépendances dans un magasin virtuel `.pnpm`, sous des répertoires au nom haché : la CLI arrivait sans les siennes. Elle est désormais installée par npm, qui produit une disposition plate, copiable telle quelle. La version est lue dans package.json plutôt que figée, pour qu'elle ne diverge pas au premier changement. Tout ce qui sert aux migrations — modules, schéma, configuration — vit dans un arbre séparé. Les superposer aux modules de l'application les ferait entrer en collision : la sortie `standalone` porte `react` en lien symbolique vers le magasin pnpm, là où l'installation npm l'apporte en répertoire réel. Deux arbres n'ont rien à s'écraser. `prisma.config.ts` n'importe plus `dotenv` de façon ferme : la sortie `standalone` n'embarque que ce que le serveur utilise, et `dotenv` n'en fait pas partie — l'import aurait fait échouer les migrations au démarrage. Cette fois l'image a été reconstituée à l'identique et **démarrée** : clé produite, migrations appliquées, serveur prêt, `/connexion` en 200 et `/api/sante` rapportant `tenantIsolation: enforced`. C'est ce que j'aurais dû faire aux trois tentatives précédentes, où je n'avais éprouvé que des morceaux. La simulation a d'ailleurs trouvé un chemin `/migrator` en dur dans le point d'entrée ; il est désormais surchargeable, comme l'emplacement de la clé. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv
42 lines
1.5 KiB
TypeScript
42 lines
1.5 KiB
TypeScript
import { defineConfig } from 'prisma/config';
|
|
|
|
/*
|
|
* `.env` est pratique en développement, absent en conteneur — où les variables
|
|
* viennent de l'environnement et où `dotenv` n'est pas installé : la sortie
|
|
* `standalone` de Next n'embarque que ce que le serveur utilise. Un import
|
|
* ferme ferait échouer les migrations au démarrage de l'image.
|
|
*/
|
|
try {
|
|
await import('dotenv/config');
|
|
} catch {
|
|
// Rien à charger : les variables sont déjà dans l'environnement.
|
|
}
|
|
|
|
/**
|
|
* Prisma 7 moved the migration connection URL out of schema.prisma.
|
|
*
|
|
* Only the CLI reads this file. The application connects through the pg driver
|
|
* adapter in src/server/db.ts, which is what lets WP-01 wrap every query in the
|
|
* tenant-scoping extension required by PLAN.md §3.1.
|
|
*/
|
|
export default defineConfig({
|
|
schema: 'prisma/schema.prisma',
|
|
migrations: {
|
|
path: 'prisma/migrations',
|
|
seed: 'tsx prisma/seed.ts',
|
|
},
|
|
datasource: {
|
|
/*
|
|
* Lu directement plutôt que par `env()`, qui échoue dès le **chargement**
|
|
* du fichier de configuration quand la variable manque.
|
|
*
|
|
* Or ce fichier est chargé par toutes les commandes du CLI, y compris
|
|
* `prisma generate`, qui ne se connecte à rien : la construction de l'image
|
|
* devenait impossible sans fournir une base au constructeur. Les commandes
|
|
* qui ont réellement besoin de l'URL — `migrate` — échouent d'elles-mêmes,
|
|
* au moment où elle leur manque.
|
|
*/
|
|
url: process.env.DATABASE_URL ?? '',
|
|
},
|
|
});
|