seedly

Remplit votre base de développement avec des données cohérentes, en lisant votre schéma PostgreSQL. Pas de fichier de seed à écrire, pas de fixtures à maintenir.

npx @elirames/seedly --url postgres://localhost/mon_app_dev --rows users=50,orders=200

✓ 12 tables analysées
✓ ordre d'insertion résolu
✓ 50 users, 200 orders, 137 order_items insérés en 340 ms
  graine : 42 — relancez avec --seed 42 pour le même jeu de données

Le problème

Vous démarrez une fonctionnalité. Il vous faut des clients, des commandes, des lignes de commande — cohérents entre eux, respectant vos clés étrangères et vos contraintes d'unicité. Alors vous écrivez un fichier de seed. Puis le schéma change, et le fichier ne compile plus. Vous le réparez. Puis un collègue ajoute une colonne NOT NULL, et ça recommence.

Un fichier de seed est une copie du schéma, écrite à la main, qui se périme.

seedly ne duplique rien : il lit le schéma réel, dans la base réelle, à l'instant où vous lancez la commande.

Pourquoi lire la base plutôt que l'ORM

seedly interroge le catalogue PostgreSQL — information_schema, pg_enum, pg_constraint. Il ne sait pas quel outil a créé vos tables, et c'est précisément l'intérêt : il fonctionne avec Prisma, Drizzle, TypeORM, Sequelize, Rails, Django, Laravel, ou du SQL écrit à la main.

Une seule implémentation, aucun adaptateur à maintenir.

Ce qu'il comprend

| Élément du schéma | Effet sur les données générées | |---|---| | Clés étrangères | ordre d'insertion, valeurs qui pointent vers des lignes existantes | | Contraintes d'unicité | aucune collision, y compris sur les contraintes composites | | Types énumérés | valeurs tirées parmi celles déclarées | | NOT NULL | jamais de valeur nulle là où c'est interdit | | Longueurs (varchar(n)) | texte tronqué à la bonne taille | | Nom de colonne | email cohérent avec le nom de la ligne, city/country en paire réelle, price → un montant | | Cycles de clés étrangères | insérés en deux temps (NULL puis mise à jour), auto-références comprises |

Deux détails qui font la différence

Les données d'une ligne sont cohérentes entre elles. updated_at tombe après created_at, l'e-mail reprend le prénom et le nom de la ligne, la ville va avec le bon pays. Des valeurs valides mais incohérentes masquent exactement les bugs qu'on cherche à trouver — et trahissent la donnée générée à l'œil nu.

Les clés étrangères ne sont pas réparties uniformément. 200 commandes sur 50 clients ne donnent pas 4 commandes chacun : quelques clients en ont trente, beaucoup n'en ont aucune. C'est cette forme-là qui fait ressortir les requêtes lentes et les pages qui débordent.

Déterminisme

Toute la génération dérive d'une graine.

seedly --seed 42    # produit toujours exactement le même jeu de données

Votre équipe partage les mêmes données. Un bug trouvé sur un jeu de données se reproduit à l'identique : il suffit de noter la graine dans le ticket.

Options

| Option | Défaut | Rôle | |---|---|---| | --url | $DATABASE_URL | chaîne de connexion PostgreSQL | | --rows | 10 par table | volumes, ex. users=50,orders=200 | | --seed | aléatoire | graine de génération | | --schema | public | schéma à peupler | | --only | — | limite à certaines tables | | --exclude | — | ignore certaines tables | | --truncate | false | vide les tables avant d'insérer | | --dry-run | false | affiche le plan sans rien écrire |

Sécurité

seedly écrit dans votre base. Il refuse de s'exécuter si l'URL de connexion ne pointe pas vers localhost, sauf --i-know-what-im-doing.

État

Version 0.5 — en construction.

• [x] Introspection du schéma
• [x] Tri topologique des tables
• [x] Insertion transactionnelle
• [x] Contraintes d'unicité et types énumérés
• [x] Inférence par nom de colonne
• [x] Distribution réaliste
• [x] Cycles de clés étrangères

Reste avant la 1.0 : polissage des tests, documentation, publication sur npm.

Construit avec l'IA

Ce projet a été conçu et écrit en binôme avec Claude (Anthropic) — conception, code et tests. C'est assumé : un truc cool, fait honnêtement.

Licence

MIT