Nach Snaplet Seed: seed.ts ersetzen, ohne ein neues Seed-Script zu schreiben

Hier eine praktische Antwort darauf. Kein Feature-Pitch, nur: was seed.ts wirklich gemacht hat, was du behalten kannst, und wie du die Teile ersetzt, die jetzt eingefroren sind.

Was mit Snaplet Seed passiert ist

Snaplet hat seine Produkte im August 2024 eingestellt. Das Team ging zu Supabase, das Tooling wurde open-source, und @snaplet/seed ging an die Community. Das letzte Release mit echter Feature-Arbeit war v0.98.0 am 30. Juli 2024. Der Fork installiert noch, aber seither bewegt sich kaum etwas, und "kaum etwas" ist ein Problem für ein Tool, das bei jedem CI-Lauf zwischen deinem Prisma-Schema und der Datenbank sitzt.

Das Paket ist also nicht weg. Es ist eingefroren. Der Unterschied zählt, denn ein eingefrorenes Seed-Tool läuft genau so lange, bis ein Prisma-Versionssprung, ein Node-Upgrade oder ein neuer Spaltentyp es klammheimlich zerlegt. Meistens freitags.

Was seed.ts für dich gemacht hat

Der Wert von Snaplet Seed war createSeedClient. Du hast deine Daten in TypeScript beschrieben, und es ist durch dein Prisma-Schema gelaufen, um die Foreign Keys gültig zu halten:

import { createSeedClient } from "@snaplet/seed"

const seed = await createSeedClient()
await seed.users((x) => x(10, {
  posts: (x) => x(3),
}))

Zehn User, je drei Posts, jede post.authorId zeigt auf eine echte user.id. Die Schema-Kenntnis ist der Teil, den es zu retten lohnt. Das TypeScript-Seed-Script ist der Teil, den man sich nochmal überlegen sollte, denn genau diese Datei rottet: Jede Schema-Änderung heißt seed.ts anfassen, und ein 200-Zeilen-Seed-Script ist seine eigene kleine Codebase, die gepflegt werden will.

Option 1, beim Fork bleiben

Vertretbar, wenn dein seed.ts klein ist, dein Stack gepinnt ist und du die Wartung selbst stemmen kannst. Du wettest darauf, dass sich nichts in deiner Toolchain schneller bewegt, als der Community-Fork hinterherkommt. Für viele Teams geht die Wette noch ein halbes Jahr gut und hört dann leise auf, gut zu gehen.

Option 2, das Seed-Script wegwerfen und aus dem Schema generieren

Die Alternative ist, die Seed-Logik gar nicht mehr von Hand zu schreiben. Statt einer TypeScript-Datei, die Zeilen beschreibt, richtest du einen Generator direkt aufs Schema und lässt ihn Foreign-Key-konsistente Daten erzeugen. Bei SeedBase ist das das Schema plus eine Zeilenzahl, kein seed.ts:

• Prisma-Schema importieren (oder SQL, oder Django-Modelle).
• Es liest den Foreign-Key-Graphen und erzeugt Eltern vor Kindern, sodass jede Referenz aufgeht.
• Als SQL, CSV oder JSON exportieren, oder direkt nach Postgres oder MySQL pushen.

Was du von Snaplet behältst, FK-korrekte Daten, behältst du. Was du gewartet hast, seed.ts, löschst du. Das ist der eigentliche Tausch, und für die meisten Teams, die ein ungewartetes Tool verlassen, ist Code löschen genau der Punkt.

Falls du eh nicht auf Prisma warst

Snaplet Seed war Prisma und TypeScript first. Etliche Teams haben es eingeführt, dann einen Service in Django dazubekommen oder ein Schema, das sie nur als rohes SQL haben, und am Ende ein Prisma-förmiges Seed-Tool für eine Nicht-Prisma-Codebase gepflegt. Der Wechsel von Snaplet ist ein guter Moment, das geradezuziehen: Derselbe schema-getriebene Ansatz funktioniert aus einer Django-models.py oder einem schlichten CREATE TABLE-Dump, nicht nur aus schema.prisma.

CI deterministisch halten nach dem Wechsel

Das eine Snaplet-Verhalten, das du nicht verlieren willst, ist Reproduzierbarkeit. Seed-basierte Generierung sollte deterministisch sein: Derselbe Seed-Wert erzeugt dieselben Zeilen, sodass ein fehlschlagender CI-Lauf debugbar ist statt "geht beim dritten Versuch". Pinn den Seed in deiner Pipeline, und der Datensatz ist über Läufe und Maschinen hinweg stabil.

FAQ

Ist @snaplet/seed 2026 noch nutzbar?

Es installiert noch, aber das letzte Feature-Release war v0.98.0 im Juli 2024, und es wird von der Community mit wenig Bewegung gepflegt. Es läuft, bis eine Dependency oder Schema-Änderung es zerlegt, ohne Maintainer, der das schnell fixt.

Muss ich mein seed.ts zum Migrieren neu schreiben?

Nein. Der Sinn eines schema-getriebenen Generators ist, dass du das Seed-Script gar nicht portierst. Du importierst das Schema, generierst daraus und löschst seed.ts.

Kann ich Snaplet Seed ohne Prisma ersetzen?

Ja. Schema-getriebene Generierung funktioniert auch aus SQL-Dumps und Django-Modellen, nicht nur aus schema.prisma, praktisch, wenn dein Stack über Prisma hinausgewachsen ist.

Bleiben die generierten Daten Foreign-Key-gültig?

Ja. Der Generator ordnet die Inserts nach dem Foreign-Key-Graphen, Eltern vor Kindern, sodass jede Referenz aufgeht, dieselbe Garantie, die dir createSeedClient gegeben hat.