fix(portal-bff): downgrade Prisma to 6.x for nestjs-prisma compatibility #3
Reference in New Issue
Block a user
Delete Branch "fix/portal-bff/prisma-client-generator"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
prismaand@prisma/clientto^6(resolved 6.19.3) instead of the previous^7.apps/portal-bff/prisma/schema.prismafromprisma-clienttoprisma-client-js(Prisma 6's default).url = env("DATABASE_URL")in thedatasource dbblock (required by Prisma 6; was implicit in Prisma 7 viaprisma.config.ts).apps/portal-bff/prisma.config.ts(Prisma 7-only feature)./generated/prismaentry fromapps/portal-bff/.gitignore.Motivation
Two distinct Prisma 7 breaking changes surfaced as runtime errors in
pnpm nx serve portal-bff:Generator output path: Prisma 7's default
prisma-clientgenerator writes to a custom output dir declared in the schema.@prisma/client/default.js's runtime stub still resolves.prisma/client/defaultin a siblingnode_modules/.prisma/client/, which only the legacyprisma-client-jsgenerator populates. Result:ESM loader error: Cannot find module '.prisma/client/default'.PrismaClientOptions API: In Prisma 7,
PrismaClientOptionsno longer exposesdatasourceUrlnordatasources. The connection must come through a driver adapter (e.g.@prisma/adapter-pg).nestjs-prisma@0.27.0callssuper(undefined)when noprismaServiceOptionsis passed, which Prisma 7 rejects withPrismaClientInitializationError: PrismaClient needs to be constructed with a non-empty, valid PrismaClientOptions.Both issues are downstream of Prisma 7's "adapter-first" architecture being incompatible with
nestjs-prisma's still-Prisma-6-shaped wrapper. Working around each issue separately would lead into bespoke wiring (custom PrismaService, manual@prisma/adapter-pginstall, hand-rolled DI). That's bricolage on a foundational layer.Per CLAUDE.md ("default to stable, recognized, battle-tested choices; cutting-edge alternatives only when the trade-off is captured in an ADR"), the cheapest, cleanest fix is to use Prisma 6 — still actively maintained, fully aligned with
nestjs-prisma's design, supported by every tutorial and example in the wider ecosystem.Implementation notes
apps/portal-bff/.env.exampleis unchanged — theDATABASE_URLvariable name is the same in Prisma 6 and 7.prisma.config.tsremoved: it was a Prisma 7 file that Prisma 6 ignores; keeping it would only confuse a future contributor.prisma-clientgenerator left a residual output dir atapps/portal-bff/generated/from the previous setup; removed locally and excluded from gitignore (no longer needed).nestjs-prismareleases an update aligned with Prisma 7's adapter model. The path back is symmetric: pin Prisma to^7, restore the schema'sprisma-clientgenerator, install@prisma/adapter-pg, and updateapp.module.tsto instantiate the adapter.Verification
pnpm exec prisma generatepopulatesnode_modules/.../@prisma+client@6.19.3/.prisma/client/default.js(no more 7.x in the active resolution).pnpm nx build portal-bffgreen.pnpm nx serve portal-bffboots cleanly (noPrismaClientInitializationError) — to be confirmed locally before merge. Connection to a real Postgres is out of scope of this PR; if Postgres is not running, anECONNREFUSEDis expected and unrelated.pnpm ci:check— runs in CI on PR open.Related
nestjs-prismaships an update with first-class driver-adapter support.Prisma 7 introduced two breaking changes that conflict with nestjs-prisma 0.27.0: 1. The `prisma-client` provider (new default in Prisma 7) outputs the typed client to a custom path declared in schema.prisma. nestjs-prisma's PrismaService extends @prisma/client's runtime, which boots through @prisma/client/default.js — that stub requires `.prisma/client/default` in a sibling node_modules tree. Only the legacy `prisma-client-js` generator populates that path. 2. PrismaClientOptions in Prisma 7 no longer exposes `datasourceUrl` nor `datasources`. Connection now requires a driver adapter (e.g. `@prisma/adapter-pg` for Postgres). nestjs-prisma 0.27.0 does not pass an adapter, and `new PrismaClient(undefined)` is rejected with `PrismaClientInitializationError: PrismaClient needs to be constructed with a non-empty, valid PrismaClientOptions`. Both quirks are Prisma 7's adapter-first architecture surfacing through a still-Prisma-6-shaped wrapper. nestjs-prisma's peer-deps say `^7.0.0` but its design assumes the older API. Working around each issue separately leads further into bespoke wiring (custom PrismaService, manual @prisma/adapter-pg setup) — bricolage on a foundational layer. Per CLAUDE.md ("default to stable, recognized, battle-tested choices"), downgrade to Prisma 6.19 (still actively maintained): - package.json: prisma + @prisma/client pinned to ^6 (resolved 6.19.3) - apps/portal-bff/prisma/schema.prisma: - generator client: `prisma-client-js` (Prisma 6 default) - datasource db: explicit `url = env("DATABASE_URL")` (required by Prisma 6, was implicit in Prisma 7 via prisma.config.ts) - apps/portal-bff/prisma.config.ts: removed (Prisma 7-only feature) - apps/portal-bff/.gitignore: drop the now-irrelevant `/generated/prisma` entry (no custom output dir with prisma-client-js) ADR-0006 ("Persistence — PostgreSQL with Prisma") is unchanged: it specifies Prisma without pinning a version. The version choice is a tactical detail. Re-evaluate when nestjs-prisma releases an update aligned with Prisma 7's adapter model. Verified: pnpm exec prisma generate populates Prisma 6's .prisma/client/default.{js,d.ts}; pnpm nx build portal-bff green. Runtime serve to be re-verified locally before merge.