Så här åtgärdar du felet ”Prisma Client has not been generated yet”

Om din app kraschar med Prisma Client has not been generated yet är det snabbaste användbara svaret inte att radera allt och installera om blint. Ta först reda på vilken Prisma Client-generator ditt projekt använder, generera klienten från rätt schema och se till att din applikation importerar från den plats som faktiskt genererades.

Det finns en viktig versionsrelaterad källa till förvirring. Enligt en kontroll i september 2026 använder Prisma 7-dokumentationen generatorn prisma-client med en obligatorisk output-katalog, och applikationskoden importerar Prisma Client från den genererade sökvägen. Äldre och fortfarande vanliga projekt använder prisma-client-js, där @prisma/client är den normala importen och genererade projektspecifika filer traditionellt har legat under node_modules/.prisma/client. Om man blandar dessa två uppsättningar instruktioner kan man hamna i en situation där klienten genereras på ett ställe medan applikationskoden importerar från ett annat. Den officiella guiden för generering av Prisma Client dokumenterar det aktuella beteendet i Prisma 7.

Snabb diagnos: vad felet vanligtvis betyder

1. Läs felet innan du ändrar beroenden

Den bekräftade delen är enkel: Prisma Client är genererad kod anpassad till ditt schema. Om körtiden importerar en klientingångspunkt vars genererade implementation saknas, är inaktuell eller inte finns där importen förväntar sig den, kan uppstarten misslyckas innan din första databasfråga körs.

Det som inte bevisas av enbart detta meddelande är att din databas är nere, att dina autentiseringsuppgifter är fel eller att dina migreringar misslyckades. Dessa förhållanden kan orsaka andra Prisma-fel, men detta specifika meddelande pekar dig först mot generering och modulupplösning.

Åtgärd: notera det exakta paketet, filen och importsökvägen i stackspårningen. Kontrollera sedan generatorblocket i schemat innan du installerar om något.

2. Identifiera din generator och förväntade importsökväg

Öppna prisma/schema.prisma eller den schemasökväg som är konfigurerad för ditt projekt. Generatorn avgör var Prisma Client skapas och hur du bör importera den.

Aktuellt prisma-client-mönster i Prisma 7

generator client {
  provider = "prisma-client"
  output   = "../generated/prisma"
}

Med detta mönster importerar du från den utdata du konfigurerade, till exempel:

import { PrismaClient } from "../generated/prisma/client";

Prismas aktuella dokumentation anger att output är obligatoriskt för Prisma 7-generatorn prisma-client och att importer sker från den genererade platsen.

Äldre prisma-client-js-mönster

generator client {
  provider = "prisma-client-js"
}

I denna äldre struktur använder applikationskoden vanligtvis:

import { PrismaClient } from "@prisma/client";

Åtgärd: ändra inte importen bara för att en handledning använder en annan generator. Matcha importen mot ditt eget schema och din version.

3. Validera schemat och generera sedan klienten

Innan du genererar, validera schemat. Prisma tillhandahåller prisma validate specifikt för att kontrollera schemats syntax och konfiguration. Den officiella referensen för prisma validate stöder även --schema för scheman på andra platser än standard.

npx prisma validate
npx prisma generate

Om ditt schema finns någon annanstans:

npx prisma validate --schema=./packages/database/prisma/schema.prisma
npx prisma generate --schema=./packages/database/prisma/schema.prisma

Den officiella referensen för generate-kommandot förklarar att Prisma inspekterar schemat och skriver genererade artefakter till den utdata som generatorn konfigurerat.

Åtgärd: läs den slutliga utdatan från prisma generate. Anta inte var filerna skrevs; använd sökvägen som Prisma rapporterar.

4. Verifiera att utdata finns där din kod förväntar sig den

Ett lyckat kommando är nödvändigt, men körtiden måste också se samma filer. Detta blir särskilt viktigt när byggverktyg bara kopierar en del av ett arkiv, när ett Docker-steg utelämnar genererad utdata eller när ett monorepo bygger ett paket utan att först bygga databaspaketet.

För prisma-client, inspektera den anpassade output-katalogen från schemat. För prisma-client-js, inspektera den installerade/genererade Prisma-paketstrukturen som din version använder. Betrakta inte mappen som visas i ett äldre exempel som universell.

Åtgärd: jämför tre saker sida vid sida: generatorns output, sökvägen som rapporteras av prisma generate och import-satsen i filen som kraschar. De bör beskriva samma genererade klient.

5. Åtgärda importen i stället för att generera om i evighet

Om prisma generate lyckas varje gång men samma körtidsfel kvarstår är det osannolikt att upprepade körningar hjälper. Nästa fråga är om din app importerar den genererade modul du just skapade.

För en Prisma 7-generator prisma-client visar den aktuella dokumentationen importer från den anpassade genererade sökvägen. För ett prisma-client-js-projekt är @prisma/client den förväntade paketimporten. Denna skillnad är en av de vanligaste anledningarna till att aktuella och äldre exempel verkar motsäga varandra.

Åtgärd: sök igenom ditt arkiv efter varje PrismaClient-import. I en migrering eller ett monorepo kan ett paket vara uppdaterat medan ett annat fortfarande importerar den gamla sökvägen.

6. Kontrollera Prisma-paketversioner när projektet har uppgraderats

En versionskonflikt är en omständighetsberoende orsak, inte något som detta fel bevisar i sig. Prismas uppgraderingsguider instruerar dock utvecklare att uppdatera både CLI-paketet prisma och @prisma/client vid byte av huvudversion. Den officiella uppgraderingsguiden för Prisma 7 visar att båda paketen uppgraderas tillsammans.

Kontrollera vad som faktiskt är installerat:

npm ls prisma @prisma/client

Med pnpm eller Yarn använder du motsvarande listkommando för den arbetsyta som äger Prisma. Om projektet avsiktligt stannar på Prisma 6 eller en annan version som stöds, uppgradera inte bara för att bli av med detta meddelande. Anpassa paketen till den version ditt projekt förväntar sig och generera sedan om.

Åtgärd: om versionerna blev inkonsekventa efter en sammanslagning eller beroendeuppdatering, återställ de avsedda matchande versionerna och kör prisma generate igen.

7. Gör genereringen till en del av installationen eller bygget

När en app fungerar på en utvecklarmaskin men misslyckas efter distribution ligger det saknade steget ofta i byggpipelines snarare än i applikationskoden. Prismas felsökningsdokumentation för Next.js rekommenderar specifikt att generera Prisma Client vid varje distribution när cachelagring av beroenden kan hindra generering vid installation från att köras som förväntat.

Ett enkelt paketskript är:

{
  "scripts": {
    "postinstall": "prisma generate",
    "build": "prisma generate && next build"
  }
}

Du behöver normalt en tillförlitlig genereringspunkt, inte varje möjlig hook. Välj den hook som din distributionsplattform faktiskt kör. Se Prismas officiella felsökningssida för Next.js-distribution för det cachelagringsrelaterade fallet.

Åtgärd: granska CI-loggar och bekräfta att prisma generate kördes efter att rätt schema och beroenden var tillgängliga, och före paketering eller start av servern.

8. Starta om processen efter genereringen

Utvecklingsservrar, testkörare och arbetsprocesser kan hålla moduler laddade i minnet. Att generera filer på disk garanterar inte att en process som redan misslyckats med en import automatiskt laddar om dem.

Åtgärd: stoppa och starta om utvecklingsservern, arbetaren eller testprocessen efter en lyckad generering. Om appen nu går vidare till ett annat databas- eller konfigurationsfel är det ett användbart bevis på att själva klientgenereringsproblemet är löst.

Monorepon: generera i paketet som äger schemat

I en arbetsyta är det inte automatiskt likvärdigt att köra npx prisma generate från arkivets rot som att generera inuti databaspaketet. Schemaupptäckt, konfigurationsfiler, beroenden och relativa utdatasökvägar kan alla skilja sig mellan paket.

Prismas officiella guide för pnpm-arbetsytor visar ett dedikerat databaspaket med sitt eget schema, genererade klient, hjälpskript och exporter för konsumerande appar.

Ett praktiskt mönster är:

packages/database/
  prisma/schema.prisma
  generated/client/
  client.ts
  package.json

apps/web/
  package.json

Generera från packages/database, exportera klienten från det paketet och låt applikationer bero på paketet i stället för att nå in i en annan arbetsytas privata genererade katalog.

Åtgärd: gör databaspaketets bygg- eller genereringsuppgift till ett explicit beroende för varje app som importerar det.

Behöver du radera node_modules?

Inte som första steg. Att radera node_modules kan åtgärda en skadad installation, men det kan också dölja det verkliga problemet genom att tvinga många orelaterade paket att ändras samtidigt. Om schemavalideringen lyckas och genereringen rapporterar korrekt utdata, verifiera först importer, paketversioner och byggsökvägar.

En ren ominstallation blir rimlig när paketmetadata är inkonsekvent, genererad utdata är uppenbart inaktuell efter beroendeändringar eller din pakethanterare rapporterar installationsproblem.

Åtgärd: spara npm ls prisma @prisma/client och utdatan från prisma generate före rensning. Det ger dig bevis att jämföra efter ominstallationen.

Vad detta fel inte säger dig

• Det bevisar inte i sig att din databas är onåbar. Åtgärda generering/importupplösning först och utvärdera sedan eventuella kvarvarande anslutningsfel.
• Det bevisar inte att migreringar saknas. Generering av Prisma Client och migrering av databasschemat är relaterade arbetsflöden, men de är inte samma operation.
• Det betyder inte att varje projekt bör importera från @prisma/client. Det beror på generatorn och Prisma-versionen.
• Det betyder inte att ominstallation av beroenden alltid krävs. En korrekt prisma generate plus korrekt importsökväg är ofta tillräckligt.

Checklista för förebyggande

• Kör prisma validate när schemat eller generatorns konfiguration ändras.
• Kör prisma generate efter schemaändringar och efter att ha hämtat ändringar som påverkar genererade klient-API:er.
• Håll körtidsimporten i linje med generatorns konfigurerade utdata.
• Håll versionerna av prisma och @prisma/client i linje när din valda Prisma-version använder båda paketen.
• I CI och produktion, kör generering explicit före bygge/start när cachelagring av beroenden kan hoppa över den.
• I monorepon, generera i arbetsytan som äger schemat och exponera klienten genom en stabil paketgräns.
• Starta om långvariga utvecklingsprocesser efter att ha genererat en tidigare saknad klient.

Slutsats

Den tillförlitliga lösningen är en kort kedja av bevis: identifiera din Prisma-generator, validera det avsedda schemat, generera klienten, verifiera den faktiska utdatasökvägen och se till att din import matchar den utdatan. Om problemet bara uppstår i CI eller produktion, flytta samma genereringssteg till byggarbetsflödet. Om det uppstår i ett monorepo, gör genereringen till ansvar för paketet som äger schemat.

Det tillvägagångssättet är mer pålitligt än att upprepade gånger radera beroenden eftersom det berättar vilket lager som var fel: schemaval, generering, paketversioner, importupplösning eller distributionspaketering.