Slik fikser du feilen «Prisma Client has not been generated yet»

Hvis appen din krasjer med Prisma Client has not been generated yet, er det raskeste nyttige svaret ikke å slette alt og reinstalere i blinde. Først må du finne ut hvilken Prisma Client-generator prosjektet ditt bruker, generere klienten fra riktig skjema og sørge for at applikasjonen importerer fra stedet som faktisk ble generert.

Det finnes en viktig versjonsrelatert kilde til forvirring. Per september 2026 bruker Prisma 7-dokumentasjonen generatoren prisma-client med en påkrevd output-katalog, og applikasjonskoden importerer Prisma Client fra den genererte stien. Eldre og fortsatt vanlige prosjekter bruker prisma-client-js, der @prisma/client er den normale importen og genererte prosjektspesifikke filer tradisjonelt har ligget under node_modules/.prisma/client. Hvis du blander de to instruksjonssettene, kan du ende opp med en generert klient på ett sted og applikasjonskode som importerer et annet. Den offisielle veiledningen for generering av Prisma Client dokumenterer gjeldende oppførsel i Prisma 7.

Rask diagnose: hva feilen vanligvis betyr

1. Les feilen før du endrer avhengigheter

Den bekreftede delen er enkel: Prisma Client er generert kode tilpasset skjemaet ditt. Hvis kjøretiden importerer et inngangspunkt for klienten der den genererte implementasjonen mangler, er utdatert eller ikke ligger der importen forventer, kan oppstarten feile før den første databasespørringen din kjøres.

Det denne meldingen alene ikke beviser, er at databasen din er nede, at påloggingsinformasjonen er feil, eller at migreringene dine feilet. Disse tilstandene kan forårsake andre Prisma-feil, men denne spesifikke meldingen peker deg først mot generering og moduloppslag.

Handling: noter den nøyaktige pakken, filen og importstien i stakksporet. Sjekk deretter generatorblokken i skjemaet før du reinstalerer noe.

2. Identifiser generatoren din og forventet importsti

Åpne prisma/schema.prisma eller skjemastien som er konfigurert for prosjektet ditt. Generatoren bestemmer hvor Prisma Client opprettes, og hvordan du skal importere den.

Gjeldende prisma-client-mønster i Prisma 7

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

Med dette mønsteret importerer du fra utdataene du konfigurerte, for eksempel:

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

Prismas gjeldende dokumentasjon sier at output er påkrevd for prisma-client-generatoren i Prisma 7, og at importer kommer fra den genererte plasseringen.

Eldre prisma-client-js-mønster

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

I dette eldre oppsettet bruker applikasjonskoden vanligvis:

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

Handling: ikke endre importen bare fordi en veiledning bruker en annen generator. Tilpass importen til ditt eget skjema og din egen versjon.

3. Valider skjemaet, og generer deretter klienten

Før du genererer, må du validere skjemaet. Prisma tilbyr prisma validate spesielt for å sjekke skjemasyntaks og konfigurasjon. Den offisielle referansen for prisma validate støtter også --schema for skjemaplasseringer som ikke er standard.

npx prisma validate
npx prisma generate

Hvis skjemaet ligger et annet sted:

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

Den offisielle referansen for generate-kommandoen forklarer at Prisma inspiserer skjemaet og skriver genererte artefakter til utdataene som er konfigurert av generatoren.

Handling: les den endelige utdataen fra prisma generate. Ikke anta hvor filene ble skrevet; bruk stien Prisma rapporterer.

4. Verifiser at utdataene finnes der koden din forventer dem

En vellykket kommando er nødvendig, men kjøretiden må også se de samme filene. Dette blir spesielt viktig når byggeverktøy bare kopierer en del av et repositorium, når et Docker-trinn utelater genererte utdata, eller når et monorepo bygger én pakke uten først å bygge databasepakken.

For prisma-client inspiserer du den egendefinerte output-katalogen fra skjemaet. For prisma-client-js inspiserer du oppsettet for den installerte/genererte Prisma-pakken som versjonen din bruker. Ikke behandle mappen som vises i et eldre eksempel, som universell.

Handling: sammenlign tre ting side om side: generatorens output, stien som rapporteres av prisma generate, og importsetningen i filen som krasjer. De skal beskrive den samme genererte klienten.

5. Rett importen i stedet for å generere på nytt i det uendelige

Hvis prisma generate lykkes hver gang, men den samme kjøretidsfeilen vedvarer, er det lite sannsynlig at det hjelper å kjøre den på nytt og på nytt. Det neste spørsmålet er om appen din importerer den genererte modulen du nettopp opprettet.

For en prisma-client-generator i Prisma 7 viser gjeldende dokumentasjon importer fra den egendefinerte genererte stien. For et prisma-client-js-prosjekt er @prisma/client den forventede pakkeimporten. Denne forskjellen er en av de vanligste grunnene til at gjeldende og eldre eksempler ser ut til å motsi hverandre.

Handling: søk gjennom repositoriet ditt etter alle PrismaClient-importer. I en migrering eller et monorepo kan én pakke være oppdatert mens en annen fortsatt importerer den gamle stien.

6. Sjekk Prisma-pakkeversjoner når prosjektet er oppgradert

Et versjonsavvik er en situasjonsavhengig årsak, ikke noe denne feilen beviser i seg selv. Prismas oppgraderingsveiledninger instruerer imidlertid utviklere om å oppdatere både prisma-CLI-pakken og @prisma/client ved overgang til nye hovedversjoner. Den offisielle oppgraderingsveiledningen for Prisma 7 viser at begge pakkene oppgraderes sammen.

Sjekk hva som faktisk er installert:

npm ls prisma @prisma/client

Med pnpm eller Yarn bruker du tilsvarende listekommando for arbeidsområdet som eier Prisma. Hvis prosjektet bevisst holder seg på Prisma 6 eller en annen støttet versjon, må du ikke oppgradere bare for å fjerne denne meldingen. Tilpass pakkene til versjonen prosjektet ditt forventer, og generer deretter på nytt.

Handling: hvis versjonene ble inkonsekvente etter en sammenslåing eller avhengighetsoppdatering, gjenopprett de tiltenkte samsvarende versjonene og kjør prisma generate igjen.

7. Gjør generering til en del av installasjonen eller bygget

Når en app fungerer på en utviklermaskin, men feiler etter distribusjon, ligger det manglende trinnet ofte i byggepipelinen snarere enn i applikasjonskoden. Prismas feilsøkingsdokumentasjon for Next.js anbefaler spesifikt å generere Prisma Client ved hver distribusjon når avhengighetsbufring kan hindre at generering ved installasjon kjører som forventet.

Et enkelt pakkeskript er:

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

Du trenger vanligvis ett pålitelig genereringspunkt, ikke alle mulige hooks. Velg hooken som distribusjonsplattformen din faktisk kjører. Se Prismas offisielle feilsøkingsside for Next.js-distribusjon for det bufringsrelaterte tilfellet.

Handling: inspiser CI-logger og bekreft at prisma generate kjørte etter at riktig skjema og avhengigheter var tilgjengelige, og før bunting eller oppstart av serveren.

8. Start prosessen på nytt etter generering

Utviklingsservere, testkjørere og arbeidsprosesser kan holde moduler lastet i minnet. Å generere filer på disk garanterer ikke at en prosess som allerede har feilet med en import, laster dem inn automatisk.

Handling: stopp og start utviklingsserveren, arbeidsprosessen eller testprosessen på nytt etter en vellykket generering. Hvis appen nå går videre til en annen database- eller konfigurasjonsfeil, er det nyttig bevis på at selve problemet med klientgenerering er løst.

Monorepos: generer i pakken som eier skjemaet

I et arbeidsområde er det ikke automatisk det samme å kjøre npx prisma generate fra repositoriets rot som å generere inne i databasepakken. Skjemaoppdagelse, konfigurasjonsfiler, avhengigheter og relative utdatastier kan alle variere fra pakke til pakke.

Prismas offisielle veiledning for pnpm-arbeidsområder viser en dedikert databasepakke med sitt eget skjema, genererte klient, hjelpeskript og eksporter for apper som bruker den.

Et praktisk mønster er:

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

apps/web/
  package.json

Generer fra packages/database, eksporter klienten fra den pakken, og la applikasjoner være avhengige av pakken i stedet for å hente fra et annet arbeidsområdes private genererte katalog.

Handling: gjør databasepakkens bygge- eller genereringsoppgave til en eksplisitt avhengighet for enhver app som importerer den.

Trenger du å slette node_modules?

Ikke som første trinn. Å slette node_modules kan fikse en skadet installasjon, men det kan også skjule det virkelige problemet ved å tvinge mange urelaterte pakker til å endre seg samtidig. Hvis skjemavalidering lykkes og genereringen rapporterer riktig utdata, må du først verifisere importer, pakkeversjoner og byggestier.

En ren reinstallasjon blir rimelig når pakkemetadata er inkonsekvente, genererte utdata tydelig er utdaterte etter avhengighetsendringer, eller pakkehåndteringen rapporterer installasjonsproblemer.

Handling: ta vare på npm ls prisma @prisma/client og utdataen fra prisma generate før opprydding. Det gir deg bevis å sammenligne med etter reinstallasjon.

Hva denne feilen ikke forteller deg

• Den beviser ikke i seg selv at databasen din er utilgjengelig. Fiks generering/importoppslag først, og vurder deretter eventuelle tilkoblingsfeil som gjenstår.
• Den beviser ikke at migreringer mangler. Generering av Prisma Client og migrering av databaseskjemaet er beslektede arbeidsflyter, men de er ikke samme operasjon.
• Den betyr ikke at alle prosjekter bør importere fra @prisma/client. Det avhenger av generatoren og Prisma-versjonen.
• Den betyr ikke at det alltid er nødvendig å reinstalere avhengigheter. En korrekt prisma generate pluss korrekt importsti er ofte nok.

Sjekkliste for forebygging

• Kjør prisma validate når skjemaet eller generatorkonfigurasjonen endres.
• Kjør prisma generate etter skjemaendringer og etter å ha hentet endringer som påvirker genererte klient-API-er.
• Hold kjøretidsimporten i samsvar med generatorens konfigurerte utdata.
• Hold versjonene av prisma og @prisma/client i samsvar når Prisma-versjonen du har valgt, bruker begge pakkene.
• I CI og produksjon: kjør generering eksplisitt før bygg/oppstart når avhengighetsbufring kan hoppe over den.
• I monorepos: generer i arbeidsområdet som eier skjemaet, og eksponer klienten gjennom en stabil pakkegrense.
• Start langvarige utviklingsprosesser på nytt etter å ha generert en klient som tidligere manglet.

Konklusjon

Den pålitelige løsningen er en kort kjede av bevis: identifiser Prisma-generatoren din, valider det tiltenkte skjemaet, generer klienten, verifiser den faktiske utdatastien og få importen til å samsvare med den utdataen. Hvis problemet bare oppstår i CI eller produksjon, flytter du det samme genereringstrinnet inn i byggearbeidsflyten. Hvis det oppstår i et monorepo, gjør du generering til ansvaret til pakken som eier skjemaet.

Denne tilnærmingen er mer pålitelig enn å slette avhengigheter gjentatte ganger, fordi den forteller deg hvilket lag som var feil: skjemavalg, generering, pakkeversjoner, importoppslag eller distribusjonspakking.