Sådan retter du fejlen "Prisma Client Has Not Been Generated Yet"

Hvis din app crasher med Prisma Client has not been generated yet, er det hurtigste nyttige svar ikke at slette alt og geninstallere i blinde. Først skal du afgøre, hvilken Prisma Client-generator dit projekt bruger, generere klienten fra det korrekte schema og sikre, at din applikation importerer fra det sted, der faktisk blev genereret.

Der er en vigtig versionsrelateret kilde til forvirring. Som kontrolleret i september 2026 bruger Prisma 7-dokumentationen generatoren prisma-client med en påkrævet output-mappe, og applikationskoden importerer Prisma Client fra den genererede sti. Ældre og stadig almindelige projekter bruger prisma-client-js, hvor @prisma/client er den normale import, og genererede projektspecifikke filer traditionelt har ligget under node_modules/.prisma/client. Hvis du blander de to sæt instruktioner, kan du ende med en genereret klient ét sted og applikationskode, der importerer et andet sted. Den officielle Prisma Client-generationsvejledning dokumenterer den aktuelle Prisma 7-adfærd.

Hurtig diagnose: hvad fejlen normalt betyder

1. Læs fejlen, før du ændrer afhængigheder

Den bekræftede del er enkel: Prisma Client er genereret kode, der er tilpasset dit schema. Hvis runtime importerer et klient-entry point, hvis genererede implementering mangler, er forældet eller ikke ligger, hvor importen forventer det, kan opstart fejle, før din første databaseforespørgsel kører.

Det, der ikke bevises af denne meddelelse alene, er, at din database er nede, at dine legitimationsoplysninger er forkerte, eller at dine migreringer fejlede. Disse forhold kan forårsage andre Prisma-fejl, men denne specifikke meddelelse peger dig først mod generering og modulopløsning.

Handling: notér den præcise pakke, fil og importsti i stack trace. Kontrollér derefter generatorblokken i schemaet, før du geninstallerer noget.

2. Identificér din generator og forventede importsti

Åbn prisma/schema.prisma eller den schemasti, der er konfigureret til dit projekt. Generatoren bestemmer, hvor Prisma Client oprettes, og hvordan du skal importere den.

Aktuelt Prisma 7 prisma-client-mønster

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

Med dette mønster importerer du fra det output, du konfigurerede, for eksempel:

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

Prismas aktuelle dokumentation angiver, at output er påkrævet for Prisma 7-generatoren prisma-client, og at imports kommer fra den genererede placering.

Legacy prisma-client-js-mønster

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

I dette ældre layout bruger applikationskode almindeligvis:

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

Handling: ændr ikke importen, blot fordi en vejledning bruger en anden generator. Tilpas importen til dit eget schema og din version.

3. Validér schemaet, og generér derefter klienten

Før du genererer, skal du validere schemaet. Prisma tilbyder prisma validate specifikt til at kontrollere schemastaks og konfiguration. Den officielle prisma validate-reference understøtter også --schema til ikke-standard placeringer af schemaet.

npx prisma validate
npx prisma generate

Hvis dit schema ligger et andet sted:

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

Den officielle reference for generate-kommandoen forklarer, at Prisma inspicerer schemaet og skriver genererede artefakter til det output, der er konfigureret af generatoren.

Handling: læs det endelige output fra prisma generate. Antag ikke, hvor filerne blev skrevet; brug den sti, Prisma rapporterer.

4. Bekræft, at outputtet findes, hvor din kode forventer det

En vellykket kommando er nødvendig, men runtime skal også se de samme filer. Dette bliver især vigtigt, når build-værktøjer kun kopierer en del af et repository, når et Docker-trin udelader genereret output, eller når et monorepo bygger én pakke uden først at bygge databasepakken.

For prisma-client skal du undersøge den brugerdefinerede output-mappe fra schemaet. For prisma-client-js skal du undersøge det installerede/genererede Prisma-pakkelayout, som din version bruger. Betragt ikke mappen vist i et ældre eksempel som universel.

Handling: sammenlign tre ting side om side: generatorens output, stien rapporteret af prisma generate og import-sætningen i den fil, der crasher. De bør beskrive den samme genererede klient.

5. Ret importen i stedet for at generere i det uendelige

Hvis prisma generate lykkes hver gang, men den samme runtime-fejl fortsætter, er det usandsynligt, at gentagne kørsler hjælper. Det næste spørgsmål er, om din app importerer det genererede modul, du netop har oprettet.

For en Prisma 7 prisma-client-generator viser den aktuelle dokumentation imports fra den brugerdefinerede genererede sti. For et prisma-client-js-projekt er @prisma/client den forventede pakkeimport. Denne forskel er en af de mest almindelige årsager til, at aktuelle og ældre eksempler ser ud til at modsige hinanden.

Handling: søg i dit repository efter hver PrismaClient-import. I en migrering eller et monorepo kan én pakke være opdateret, mens en anden stadig importerer den gamle sti.

6. Kontrollér Prisma-pakkeversioner, når projektet er blevet opgraderet

En versionskonflikt er en afhængig årsag, ikke noget denne fejl beviser i sig selv. Prismas opgraderingsvejledninger instruerer dog udviklere i at opdatere både prisma-CLI-pakken og @prisma/client, når man skifter hovedversion. Den officielle Prisma 7-opgraderingsvejledning viser begge pakker blive opgraderet sammen.

Kontrollér, hvad der faktisk er installeret:

npm ls prisma @prisma/client

Med pnpm eller Yarn skal du bruge den tilsvarende list-kommando for det workspace, der ejer Prisma. Hvis projektet bevidst forbliver på Prisma 6 eller en anden understøttet version, skal du ikke opgradere blot for at fjerne denne meddelelse. Tilpas pakkerne til den version, dit projekt forventer, og generér derefter igen.

Handling: hvis versionerne blev inkonsistente efter en merge eller afhængighedsopdatering, skal du gendanne de tilsigtede matchende versioner og køre prisma generate igen.

7. Gør generering til en del af install eller build

Når en app virker på en udviklermaskine, men fejler efter deployment, ligger det manglende trin ofte i build-pipelinen snarere end i applikationskoden. Prismas fejlfindingsdokumentation for Next.js anbefaler specifikt at generere Prisma Client ved hver deployment, når afhængighedscaching kan forhindre install-time-generering i at køre som forventet.

Et simpelt package-script er:

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

Du har normalt brug for ét pålideligt genereringspunkt, ikke alle mulige hooks. Vælg det hook, som din deployment-platform faktisk udfører. Se Prismas officielle fejlfindingsside for Next.js-deployment for det caching-relaterede tilfælde.

Handling: undersøg CI-logs, og bekræft, at prisma generate kørte, efter det korrekte schema og afhængigheder var tilgængelige, og før bundling eller start af serveren.

8. Genstart processen efter generering

Udviklingsservere, test runners og worker-processer kan holde moduler indlæst i hukommelsen. Generering af filer på disken garanterer ikke, at en proces, der allerede har fejlet en import, automatisk genindlæser dem.

Handling: stop og genstart udviklingsserveren, workeren eller testprocessen efter en vellykket generering. Hvis appen nu går videre til en anden database- eller konfigurationsfejl, er det nyttigt bevis på, at selve klientgenereringsproblemet er løst.

Monorepos: generér i den pakke, der ejer schemaet

I et workspace er det ikke automatisk ensbetydende med at køre npx prisma generate fra repository-roden at generere inde i databasepakken. Schemaopdagelse, konfigurationsfiler, afhængigheder og relative output-stier kan alle variere fra pakke til pakke.

Prismas officielle pnpm workspaces-vejledning demonstrerer en dedikeret databasepakke med sit eget schema, genererede klient, hjælpescripts og eksporter til forbrugende apps.

Et praktisk mønster er:

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

apps/web/
  package.json

Generér fra packages/database, eksportér klienten fra den pakke, og lad applikationer afhænge af pakken i stedet for at nå ind i et andet workspaces private genererede mappe.

Handling: gør databasepakkens build- eller generate-opgave til en eksplicit afhængighed for enhver app, der importerer den.

Skal du slette node_modules?

Ikke som første trin. Sletning af node_modules kan rette en beskadiget installation, men det kan også skjule det egentlige problem ved at tvinge mange urelaterede pakker til at ændre sig på én gang. Hvis schemavalidering lykkes, og generering rapporterer det korrekte output, skal du først bekræfte imports, pakkeversioner og build-stier.

En ren geninstallation bliver rimelig, når pakkemetadata er inkonsistente, genereret output tydeligt er forældet efter afhængighedsændringer, eller din pakkehåndtering rapporterer installationsproblemer.

Handling: gem npm ls prisma @prisma/client og outputtet fra prisma generate, før du rydder op. Det giver dig bevis at sammenligne med efter geninstallation.

Hvad denne fejl ikke fortæller dig

• Den beviser ikke i sig selv, at din database er utilgængelig. Ret først generering/importopløsning, og vurder derefter enhver forbindelsesfejl, der måtte være tilbage.
• Den beviser ikke, at migreringer mangler. Prisma Client-generering og migrering af databaseschema er beslægtede arbejdsgange, men de er ikke den samme operation.
• Den betyder ikke, at hvert projekt skal importere fra @prisma/client. Det afhænger af generatoren og Prisma-versionen.
• Den betyder ikke, at geninstallation af afhængigheder altid er påkrævet. En korrekt prisma generate plus en korrekt importsti er ofte nok.

Tjekliste til forebyggelse

• Kør prisma validate, når schema- eller generatorkonfiguration ændres.
• Kør prisma generate efter schemaændringer og efter at have hentet ændringer, der påvirker genererede klient-API'er.
• Hold runtime-importen på linje med den konfigurerede generator-output.
• Hold versionerne af prisma og @prisma/client på linje, når din valgte Prisma-version bruger begge pakker.
• I CI og produktion skal du køre generering eksplicit før build/start, når afhængighedscaching kan springe den over.
• I monorepos skal du generere i det workspace, der ejer schemaet, og eksponere klienten gennem en stabil pakkegrænse.
• Genstart langvarige udviklingsprocesser efter generering af en tidligere manglende klient.

Konklusion

Den pålidelige løsning er en kort kæde af beviser: identificér din Prisma-generator, validér det tilsigtede schema, generér klienten, bekræft den faktiske output-sti, og få din import til at matche dette output. Hvis problemet kun opstår i CI eller produktion, skal du flytte det samme genereringstrin ind i build-workflowet. Hvis det opstår i et monorepo, skal du gøre generering til ansvaret for den pakke, der ejer schemaet.

Den tilgang er mere pålidelig end gentagne gange at slette afhængigheder, fordi den fortæller dig, hvilket lag der var forkert: schemavalget, generering, pakkeversioner, importopløsning eller deployment-pakning.