Fixing a Prisma Client Resolution Issue in a pnpm Monorepo

Introduction

While working on the RAHB project, I encountered a Prisma issue in a pnpm monorepo where prisma generate could not resolve @prisma/client.

The project uses:

• pnpm: 10.15.0
• Prisma: 6.19.3
• @prisma/client: 6.19.3
• Next.js: 15.5.24
• Backend: NestJS
• Monorepo: pnpm workspace

The interesting part was that Prisma itself was installed, but the API workspace could not correctly resolve the Prisma Client during generation.

This article documents the problem, the diagnosis, the fix, and what happened afterward.

---

The Problem

The initial command was:

pnpm --filter @rahb/api exec prisma generate --schema=../../prisma/schema.prisma

The command failed with:

Environment variables loaded from .env
Prisma schema loaded from ..\..\prisma\schema.prisma

Error: Could not resolve @prisma/client.

Please try to install it with pnpm i @prisma/client
and rerun pnpm dlx "prisma generate".

ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL
Command "prisma" not found

At first glance, this looked like a normal missing dependency problem.

However, the project was using a pnpm workspace, so dependency resolution needed to be checked at both the workspace root and the API package level.

---

Project Structure

The relevant structure was approximately:

RAHB/
└── rahb/
    ├── apps/
    │   └── api/
    ├── prisma/
    │   └── schema.prisma
    ├── package.json
    ├── pnpm-workspace.yaml
    └── node_modules/

The Prisma schema was located outside the API package:

../../prisma/schema.prisma

This meant that Prisma generation was being executed from the @rahb/api workspace while using the shared root Prisma schema.

---

Step 1: Check Prisma Versions

Before changing anything, I checked the versions installed in the API package:

pnpm --filter @rahb/api list prisma @prisma/client

The expected result was:

@rahb/api

dependencies:
@prisma/client 6.19.3

devDependencies:
prisma 6.19.3

I also checked the entire workspace:

pnpm list -r prisma @prisma/client

The result confirmed that both the workspace root and API package were using:

prisma          6.19.3
@prisma/client  6.19.3

Keeping Prisma CLI and Prisma Client on the same version is important when troubleshooting generated-client and type-resolution issues.

---

Step 2: Install Prisma Explicitly at the Workspace Root

The first attempt to add the packages normally produced a pnpm workspace warning:

ERR_PNPM_ADDING_TO_ROOT

Running this command will add the dependency to the workspace root,
which might not be what you want.

Because this was intentionally a workspace-level dependency installation, I explicitly used the -w flag:

pnpm add -D prisma@6.19.3 @prisma/client@6.19.3 -w

Then:

pnpm install

This ensured that the workspace had a consistent Prisma installation.

---

Step 3: Generate Prisma Client Again

After installing the dependencies, I ran:

pnpm --filter @rahb/api exec prisma generate --schema=../../prisma/schema.prisma

This time it succeeded:

Environment variables loaded from .env
Prisma schema loaded from ..\..\prisma\schema.prisma

✔ Generated Prisma Client (v6.19.3)

This confirmed that the original Prisma resolution problem had been fixed.

The generated client was successfully created under the pnpm-managed node_modules structure.

---

Verifying the Fix

The most important verification commands were:

pnpm --filter @rahb/api list prisma @prisma/client

and:

pnpm --filter @rahb/api exec prisma generate --schema=../../prisma/schema.prisma

The final dependency state was:

@rahb/api

dependencies:
@prisma/client 6.19.3

devDependencies:
prisma 6.19.3

And Prisma generation completed successfully:

✔ Generated Prisma Client (v6.19.3)

At this point, Prisma itself was no longer the blocker.

---

A New Problem Appeared During the Build

After Prisma generation succeeded, I ran:

pnpm --filter @rahb/api build

The build progressed further, but TypeScript compilation failed.

The output contained:

Found 15 error(s).

This distinction is important.

The project had moved from:

Prisma Client cannot be resolved

to:

TypeScript compilation errors

These are two different problems.

---

The Remaining Build Errors

The remaining errors were spread across several parts of the API.

1. Workspace Package Resolution

Cannot find module '@rahb/types'

File:

src/common/order-state-machine.ts

This is a workspace/package resolution issue and is independent of Prisma installation.

---

2. Prisma Shutdown Hook

Argument of type '"beforeExit"' is not assignable to parameter of type 'never'.

File:

src/common/prisma/prisma.service.ts

The existing Prisma shutdown-hook implementation needs to be reviewed for compatibility with Prisma 6.19.3.

---

3. Prisma Module Import Path

Cannot find module '../common/prisma/prisma.module'

File:

src/modules/admin-operations/admin-operations.module.ts

This is an incorrect or unresolved import path rather than a Prisma installation problem.

---

4. Missing DTO

Cannot find name 'UpdateProductDto'

File:

src/modules/catalog/catalog.service.ts

The existing DTO structure needs to be checked and the correct DTO imported.

---

5. Prisma JSON Type

Another error occurred when passing optionsJson to Prisma:

Type 'unknown' is not assignable to type
'NullableJsonNullValueInput | InputJsonValue | undefined'

File:

src/modules/commerce/checkout/checkout.service.ts

This is related to TypeScript typing of JSON data being passed into Prisma.

---

Redis / BullMQ Errors

Several remaining errors were unrelated to Prisma.

For example:

Type '{ ... tls: boolean }' is not assignable to type 'ConnectionOptions'

These errors appeared in the reservation and notification workers.

Affected areas included:

src/modules/commerce/workers/reservation-expiry.worker.ts

src/modules/operations/notifications/notifications.service.ts

src/modules/operations/notifications/notifications.worker.ts

The Redis connection configuration needs to match the installed BullMQ/ioredis types.

---

Prisma Relation Errors

The reservation expiry worker also contained Prisma relation errors.

For example:

'order' does not exist in type 'OrderItem$subOrderArgs'

and:

Property 'orderItem' does not exist

These errors indicate that the code was assuming relations that do not match the currently generated Prisma types.

The correct approach is to inspect:

prisma/schema.prisma

and use the relations that actually exist in the schema.

This is preferable to changing the schema simply to make TypeScript compile.

---

Delivery Query Error

Another Prisma-related TypeScript error occurred in:

src/modules/operations/delivery/delivery.service.ts

The code used:

findUnique({
  where: { orderId }
})

But the generated Prisma type reported that orderId was not a valid unique selector for DeliveryOrder.

This means the query needs to follow the actual uniqueness constraints defined by the Prisma schema.

For example, depending on the intended business logic, findFirst or another appropriate query may be more correct than findUnique.

---

Commission Rule Ordering Error

Another error appeared in:

src/modules/operations/settlements/commission.service.ts

The code attempted:

orderBy: [
  { priority: 'asc' },
  { scope: 'DESTINATION' }
]

However, Prisma expects orderBy.scope to receive a SortOrder such as:

'asc'

or:

'desc'

rather than a business enum such as:

'DESTINATION'

The business priority of commission scopes therefore needs to be implemented separately from Prisma's database sorting syntax.

---

An Important Lesson

One of the most useful lessons from this debugging process is to distinguish between:

Dependency resolution

Could not resolve @prisma/client

and:

Generated-client / TypeScript issues

TypeScript compilation errors

Fixing the first does not automatically fix the second.

In this case, once Prisma Client was successfully generated, the build exposed the actual application-level issues that had previously been hidden behind the Prisma resolution failure.

---

Final Prisma State

After the fix, the project had:

Prisma CLI:       6.19.3
@prisma/client:   6.19.3
pnpm:             10.15.0

And:

pnpm --filter @rahb/api exec prisma generate --schema=../../prisma/schema.prisma

successfully produced:

✔ Generated Prisma Client (v6.19.3)

Therefore, the original Prisma installation/resolution issue was successfully resolved.

---

What Still Needs to Be Fixed

The remaining work is application-level TypeScript cleanup:

• Resolve @rahb/types
• Fix the Prisma shutdown hook
• Correct the PrismaModule import path
• Resolve UpdateProductDto
• Correct Prisma JSON typing
• Fix Redis/BullMQ connection typing
• Correct Prisma relation queries
• Fix DeliveryOrder lookup logic
• Fix commission-rule ordering
• Remove the remaining TypeScript errors

The important constraint is that these fixes should be made without changing the existing architecture or unnecessarily changing the Prisma version.

---

Useful Debugging Commands

When working with Prisma inside a pnpm monorepo, these commands are useful:

Check package versions

pnpm --filter @rahb/api list prisma @prisma/client

Check the entire workspace

pnpm list -r prisma @prisma/client

Install matching Prisma versions

pnpm add -D prisma@6.19.3 @prisma/client@6.19.3 -w

Install workspace dependencies

pnpm install

Generate Prisma Client

pnpm --filter @rahb/api exec prisma generate --schema=../../prisma/schema.prisma

Build the API

pnpm --filter @rahb/api build

---

Conclusion

The original Prisma problem in the RAHB pnpm monorepo was caused by the workspace not correctly resolving @prisma/client when running Prisma generation from the API package.

By explicitly installing matching Prisma versions at the workspace level:

prisma          6.19.3
@prisma/client  6.19.3

and regenerating the client, Prisma Client generation was restored successfully.

The subsequent build errors were not evidence that Prisma was still broken. Instead, they revealed existing TypeScript, package-resolution, Redis/BullMQ, and Prisma relation/type issues that could then be addressed independently.

Final status:

Prisma installation       ✅
Prisma version alignment  ✅
Prisma Client generation  ✅
API TypeScript build      ⚠️ Additional code errors remain

This separation made the debugging process much clearer and prevented unnecessary changes to the project's architecture or database layer.