chore/tickets-satellite #27
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "chore/tickets-satellite"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
pnpm --filter web devdémarre sous Windows (#22) 7b0a1dee83Les scripts `dev` et `start` portaient `next dev --port ${PORT_WEB:-4000}`. pnpm passe les scripts par `cmd.exe` sous Windows, qui ne connaît pas cette substitution : la chaîne arrivait telle quelle à `next`, qui refusait. Toute l'équipe est sous Windows, donc le front ne démarrait chez personne. Le port est maintenant résolu dans `scripts/next.mjs`, en JavaScript, avant d'appeler `next`. C'est la seule forme qui se comporte pareil sur les deux plateformes — et elle n'ajoute aucune dépendance. Le script lance le point d'entrée JS de `next` avec le Node courant, pas le shim `.cmd` : passer par un shell aurait ramené `cmd.exe`, c'est-à-dire la cause du défaut. `PORT_WEB` fonctionne pour la première fois ─────────────────────────────────────────── Sous Linux, où la substitution marche, elle ne servait à rien non plus : `${PORT_WEB}` lit l'environnement du SHELL, que rien ne remplit. Le `.env` du dépôt est chargé par `next.config.mjs`, donc DANS le processus Next, bien après que `--port` a été analysé. `PORT_WEB=4000` dans `.env` n'avait donc jamais eu le moindre effet, sur aucune plateforme : `.env.example` décrivait un réglage qui n'existait pas. Le script charge le `.env` racine avant de résoudre le port, avec le même primitif que `next.config.mjs`. Vérifié à 4000 (défaut), 4321 (variable de shell) et 4567 (fichier `.env`). La variante `next-fullstack` portait le même défaut, sans être signalée. Elle n'a pas besoin d'une copie du script : son README fusionne `variantes/next-fullstack/apps/web/.` sur `apps/web/`, donc celui de la base arrive avec. Le socle gagne un contrôle bloquant `tooling.script-shell-posix` pour que la classe ne revienne pas dans la flotte. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>pnpm test:e2ene pouvait pas échouer afb28cd04apnpm devne rejoue plusprisma generate(#24) 2f0a98f993Relancer l'API pendant qu'une instance tourne échouait systématiquement sous Windows : le binaire du moteur Prisma est verrouillé par tout processus Node qui l'a chargé. EPERM: operation not permitted, rename '...\.prisma\client\query_engine-windows.dll.node.tmp102972' -> '...' Le message ne nomme ni Prisma ni la cause. On cherche un problème de droits, un antivirus, un `node_modules` corrompu — et pendant ce temps l'API qui tourne encore laisse croire que tout va bien, jusqu'à ce qu'on se demande pourquoi le code modifié ne prend pas. Et ce n'est pas un cas limite : relancer après un changement de variable, après un `git checkout`, ou parce qu'un agent a redémarré la pile, c'est le cas NORMAL en développement. Le client est déjà produit au `postinstall` et par `db:dev` (`prisma migrate dev` régénère). Le rejouer à chaque démarrage ne protégeait de rien. `db:schema` reste : la copie d'`auth.prisma` depuis `@eqs/auth` est idempotente, rapide, et c'est elle qui garde le schéma aligné sur le socle après une mise à jour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>SERVICE_NAMEn'a plus de valeur par défaut (#62), et Coolify n'est plus un acquis (#61) 1a47329f2c