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
PrismaModuleimport path - Resolve
UpdateProductDto - Correct Prisma JSON typing
- Fix Redis/BullMQ connection typing
- Correct Prisma relation queries
- Fix
DeliveryOrderlookup 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.
