@nodefony/drizzle 10.0.0-alpha.8 → 10.0.0-beta.1

package/docs/migrations.md

@@ -80,7 +80,7 @@ D'où **trois modes**, un par connecteur, réglés par la clé `ddl` :
 
 ## 🚀 Démarrage rapide
 
-Cinq verbes, et un seul à retenir pour le quotidien du développement.
+Six verbes, et un seul à retenir pour le quotidien du développement.
 
 ```bash
 # Ce que la base a reçu, ce qui reste, et ce qu'il faut taper. N'écrit rien.
@@ -117,6 +117,34 @@ Toutes acceptent `--connector <nom>` (défaut : `default`) et `--json`. Le flux
 Les migrations du **framework** sont livrées dans le paquet : vous n'avez pas à les produire. Celles
 de votre **application**, vous les écrivez avec `orm:generate` — voir la section suivante.
 
+Ces deux familles de migrations appartiennent au **seul connecteur `default`**, celui qui porte les
+briques du framework : le dossier `migrations/<dialecte>` décrit sa base, et aucune autre.
+
+Un **connecteur secondaire** (une base d'analyse, la base d'un module, un second PostgreSQL) a ses
+**propres** migrations, dans son sous-dossier :
+
+```text
+migrations/
+├── sqlite/                 ← connecteur « default » (framework + application)
+└── analytics/
+    └── postgres/           ← connecteur « analytics », et lui seul
+```
+
+```bash
+nodefony orm:generate --connector analytics --name init   # écrit sous migrations/analytics/<dialecte>
+nodefony orm:migrate  --connector analytics                # l'applique à la base d'« analytics »
+```
+
+Chaque base ne reçoit que son dossier : `default` ne voit pas les migrations d'`analytics`, et
+inversement. `orm:generate --connector analytics` ne décrit que les tables des entités déclarées sur
+ce connecteur (`@entity({ connector: "analytics" })`) ; une table qu'aucune entité ne réclame reste
+à `default`. Tant qu'un secondaire n'a rien versionné, rien ne change : en développement son schéma
+est dérivé du code. Dès son premier fichier, il bascule en `migrate` comme `default`.
+
+Un connecteur secondaire ne peut pas s'appeler `sqlite`, `postgres`, `mysql` ni `meta` : son dossier
+serait celui d'un dialecte de `default`. Les commandes qui écriraient une migration le refusent
+(`NF_MIGRATE_SECONDARY_CONNECTOR`) — renommez le connecteur, son nom ne sert qu'à le désigner.
+
 Côté configuration, il n'y a rien à écrire pour le cas courant : le mode se résout par
 environnement. Ne le déclarer que pour s'en écarter — un serveur unique qui migre au démarrage :
 
@@ -224,6 +252,14 @@ dépendances de développement (`--omit=dev`, une image de production). Le refus
 geste ; il ne parle pas de votre base, qui n'y est pour rien — appliquer des migrations, lui, ne
 réclame aucun outil tiers.
 
+Un cinquième tient à la forme d'un fichier d'entité : **un `await` de premier niveau**
+(`NF_GENERATE_TOP_LEVEL_AWAIT`). Votre application est ESM et démarre très bien avec lui, mais
+l'outil qui écrit les migrations relit les fichiers de schéma de son côté, en CommonJS, où cette
+construction n'existe pas. Le refus nomme le fichier et la ligne. Un fichier d'entité **déclare**
+une table : ce qui se décide à l'exécution — choisir une entité selon l'infrastructure, importer
+un module à la demande — se place dans l'`index.ts` du module, dont `@entities([...])` accepte une
+liste calculée.
+
 ### Une entité qui pointe vers une table du framework
 
 Déclarer une référence vers une table du framework (`session`, `audit_event`…) est légitime : ce
@@ -390,7 +426,7 @@ Trois propriétés en découlent, et elles valent d'être nommées :
 - **Rien n'est appliqué deux fois.** L'historique (`nodefony_migrations`, `types.ts:23`) est écrit
   dans la même transaction que le DDL, là où le moteur le permet.
 - **Un pod en retard ne reçoit pas de trafic.** En `none` comme en `migrate`, l'état du schéma est
-  publié à la sonde de disponibilité (`#publishReadiness()`, `DrizzleService.ts:445`) : `/readyz`
+  publié à la sonde de disponibilité (`#publishReadiness()`, `DrizzleService.ts:557`) : `/readyz`
   répond 503, l'orchestrateur sort l'exemplaire du répartiteur de charge, et l'ancien continue de
   servir. `/livez` n'est jamais touché — un schéma en retard n'est pas un processus malade, et le
   redémarrer ne réparerait rien. La vérification est rejouée toutes les 15 secondes : dès que le
@@ -454,7 +490,7 @@ qui la prend. Un outil qui prétendrait la préparer tout seul inviterait à ne
 Ce que l'outil fait à la place, et qui vaut mieux :
 
 - **il refuse d'appliquer sans que vous sachiez.** Le SQL en attente est examiné avant la moindre
-  écriture (`scanDestructive()`, `destructive.ts:184`) : une suppression de données est refusée hors
+  écriture (`scanDestructive()`, `destructive.ts:282`) : une suppression de données est refusée hors
   développement, en nommant l'instruction et ce qui disparaît. Il faut `--allow-destructive` pour
   passer outre, et **au démarrage il n'y a aucun drapeau pour lever le refus** — un exemplaire qui
   redémarre ne supprime jamais de colonne de lui-même, parce que personne ne regarde à ce

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/drizzle",
-  "version": "10.0.0-alpha.8",
+  "version": "10.0.0-beta.1",
   "description": "Moteur SQL de Nodefony sur Drizzle ORM (SQLite, PostgreSQL, MySQL) : dépôts typés, migrations de schéma et adoption d'une base existante",
   "nodefony": {
     "storeKind": "durable",
@@ -28,8 +28,8 @@
   },
   "scripts": {
     "start": "node dist/index.js",
-    "build": "rimraf dist && rolldown -c rolldown.config.ts && tsgo -p tsconfig.declarations.json",
-    "clean": "rimraf dist",
+    "build": "rolldown -c rolldown.config.ts && tsgo -p tsconfig.declarations.json",
+    "clean": "node --eval \"require('node:fs').rmSync('dist',{recursive:true,force:true})\"",
     "generate:migrations": "tsx scripts/generate-migrations.ts",
     "check:migrations": "tsx scripts/check-migrations-drift.ts",
     "dev": "rolldown -c rolldown.config.ts --watch",
@@ -55,35 +55,34 @@
     "esm"
   ],
   "dependencies": {
-    "drizzle-orm": "0.45.2",
+    "drizzle-orm": "0.45.3",
     "tslib": "2.8.1",
     "zod": "^4.6.5"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.8",
-    "@nodefony/http": "^10.0.0-alpha.8",
-    "@nodefony/orm-core": "^10.0.0-alpha.8",
-    "@nodefony/security": "^10.0.0-alpha.8",
-    "@nodefony/user": "^10.0.0-alpha.8",
+    "@nodefony/framework": "^10.0.0-beta.1",
+    "@nodefony/http": "^10.0.0-beta.1",
+    "@nodefony/orm-core": "^10.0.0-beta.1",
+    "@nodefony/security": "^10.0.0-beta.1",
+    "@nodefony/user": "^10.0.0-beta.1",
     "@types/better-sqlite3": "9.6.0",
-    "@types/node": "26.6.2",
+    "@types/node": "26.6.3",
     "@types/pg": "8.23.1",
     "better-sqlite3": "13.0.3",
-    "drizzle-kit": "0.31.10",
+    "drizzle-kit": "0.31.11",
     "mysql2": "3.24.4",
-    "nodefony": "^10.0.0-alpha.8",
-    "pg": "8.23.0",
-    "rimraf": "6.1.3"
+    "nodefony": "^10.0.0-beta.1",
+    "pg": "8.23.0"
   },
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.8",
-    "@nodefony/http": "^10.0.0-alpha.8",
-    "@nodefony/orm-core": "^10.0.0-alpha.8",
-    "@nodefony/security": "^10.0.0-alpha.8",
-    "@nodefony/user": "^10.0.0-alpha.8",
+    "@nodefony/framework": "^10.0.0-beta.1",
+    "@nodefony/http": "^10.0.0-beta.1",
+    "@nodefony/orm-core": "^10.0.0-beta.1",
+    "@nodefony/security": "^10.0.0-beta.1",
+    "@nodefony/user": "^10.0.0-beta.1",
     "better-sqlite3": "^13.0.0",
     "mysql2": "^3.24.0",
-    "nodefony": "^10.0.0-alpha.8",
+    "nodefony": "^10.0.0-beta.1",
     "pg": "^8.23.0"
   },
   "repository": {