DEV Community: Hala

Fixing a Prisma Client Resolution Issue in a pnpm Monorepo

Hala — Fri, 28 Aug 2026 14:49:54 +0000

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.

How to Fix Image Upload Failures & 404 Errors in React Native + Express/Multer

Hala — Fri, 24 Jul 2026 12:07:36 +0000

Uploading images from a React Native (Expo) client to a Node.js/Express backend using Multer is a common task, but it often comes with two frustrating issues:

TypeError: Network request failed during the upload process.
404 Not Found warnings when trying to render uploaded images in the mobile app.

Here is a breakdown of why these errors happen and how to resolve them cleanly on both the backend and client side.

The Error Logs

1. Upload Phase Error (React Native Console)

ERROR Upload error: [TypeError: Network request failed]

2. Asset Rendering Phase Warning (Expo / LogBox)

WARN Unexpected HTTP code Response{protocol=http/1.1, code=404, message=Not Found, url=http://192.168.8.101:8000/uploads/1784893610816-edeedac9.jpeg}

Root Cause Analysis

Problem 1: Unhandled Missing Upload Directory (`ENOENT`)

When using multer.diskStorage, you specify a target directory like public/uploads. Multer does not create missing folders automatically. If that folder does not exist on your server when an upload request hits the endpoint, Node.js throws an ENOENT exception, abruptly closing the socket connection. From the React Native side, this manifests as TypeError: Network request failed.

Problem 2: Incorrect Static File Route Prefix

Using app.use(express.static("public")) in Express serves the contents of the public folder directly from the root path (http://IP:PORT/filename.jpg). If your client tries to fetch http://IP:PORT/uploads/filename.jpg, Express cannot map the path correctly and returns a 404 Not Found.

Problem 3: Android File URI Formatting

Local image URIs retrieved on Android devices often require explicit formatting (uri, name, type) inside FormData to be parsed properly as a binary stream by fetch.

The Solution

1. Auto-create Directory in `multer.js`

Update your Multer configuration to check for and create the target directory dynamically using the standard fs module:

import multer from "multer";
import fs from "fs";
import path from "path";

const uploadDir = "public/uploads";

if (!fs.existsSync(uploadDir)) {
  fs.mkdirSync(uploadDir, { recursive: true });
}

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    cb(null, uploadDir);
  },
  filename: (req, file, cb) => {
    const ext = path.extname(file.originalname) || ".jpg";
    cb(null, `${Date.now()}-${Math.round(Math.random() * 1e9)}${ext}`);
  },
});

const upload = multer({ storage });

export default upload;

2. Map Static Route Correctly in `server.js`

Explicitly map requests containing the /uploads prefix to the physical public/uploads directory on disk:

import express from "express";

const app = express();

app.use("/uploads", express.static("public/uploads"));

3. Handle Client-Side Uploads in React Native (`functions.js`)

Format the image payload cleanly inside FormData before making the network call:

import { Platform } from "react-native";
import { API_URL } from "@env";

export async function uploadImage(token, localUri) {
  try {
    const filename = localUri.split("/").pop() || "profile.jpg";
    const match = /\.(\w+)$/.exec(filename);
    const type = match ? `image/${match[1]}` : "image/jpeg";

    const fileUri = Platform.OS === "android" ? localUri : localUri.replace("file://", "");

    const formData = new FormData();
    formData.append("profilePicture", {
      uri: fileUri,
      name: filename,
      type: type,
    });

    const authHeader = token?.startsWith("Bearer ") ? token : `Bearer ${token}`;

    const response = await fetch(`${API_URL}/user/profile-picture`, {
      method: "PUT",
      headers: {
        Authorization: authHeader,
        Accept: "application/json",
      },
      body: formData,
    });

    const data = await response.json();

    if (!response.ok) {
      throw new Error(data.error || data.message || `Server Error: ${response.status}`);
    }

    return data;
  } catch (error) {
    console.error("Upload error:", error);
    throw error;
  }
}

Verification & Results

Applying these updates addresses the issue on both ends:

The backend responds with HTTP status 200 OK on image upload requests.
MongoDB stores the reachable absolute URL string.
Both iOS and Android clients render the updated profile image without broken image icons or caching issues.

Conclusion

When building mobile apps with React Native and Node.js, ensure your server dynamically verifies target upload paths at runtime, and double-check that Express static route configurations mirror the URL paths requested by the frontend client.

Fixing “Please update Expo Go” error (even when it’s already updated)

Hala — Tue, 02 Jun 2026 01:49:46 +0000

While developing a React Native app using Expo, I ran into a really confusing issue.

Every time I tried to run my project, the app would open normally but immediately show this message inside the app:

“Please update Expo Go to the latest version from Google Play Store”

The strange part?
My Expo Go was already updated to the latest version from the Google Play Store.

I double-checked multiple times, uninstalled and reinstalled it, but the error still kept showing.

Environment
React Native (Expo)

Expo SDK (latest at the time of writing)

Android (Google Play Store version of Expo Go)

No errors in terminal

What I tried

Before finding the actual fix, I tried the usual debugging steps:

Reinstalling Expo Go from Google Play Store

Logging out and logging back into Expo

Reconnecting the project

Restarting Metro bundler

Clearing cache and node modules

Rebuilding the project

Nothing worked ❌

Everything looked fine… except the error inside the app.

The real issue

The problem wasn’t in my code or Expo setup.

It was a version mismatch between the Play Store Expo Go build and the required SDK version of my project.

Even though the app showed as “updated”, it was still not compatible with my project’s Expo SDK version.

The solution

Instead of relying on the Play Store version, I installed the latest Expo Go build manually from the official source.

After installing it manually:

The app launched successfully

The error disappeared immediately

Everything worked as expected

Key takeaway

If you ever see this message:

“Please update Expo Go…”

even when your app is already updated from the Play Store:

👉 Don’t assume it’s actually up to date
👉 Try installing the latest version manually from the official Expo releases instead

It saved me hours of confusion and debugging.

Final thoughts

This was one of those annoying issues where everything looks correct, but the problem is actually in version alignment between tools rather than your code.

Hopefully this helps someone avoid the same headache 🙂

How Windows Caused a Fatal “typeof” Error in Expo EAS Build — And Why Linux Solved It

Hala — Mon, 23 Mar 2026 03:26:45 +0000

Introduction

I recently faced one of the strangest and most frustrating technical issues in my development journey. My mobile application was working perfectly during development, but everything broke when I tried to build the production Android version.

What made the situation worse was that the error appeared to be unrelated to my code. After several days of troubleshooting, the solution turned out to be something I never expected: the operating system itself.

This article documents the full technical journey in hopes that it helps any developer facing a similar issue.

The Fatal Error

The project ran normally in development mode using Expo. However, when attempting to build the Android production version using EAS Build:

eas build --platform android --profile production

The process suddenly stopped and repeatedly produced the following error:

SyntaxError: Unexpected token 'typeof'
at Object.compileFunction (node:vm:360:18)
at wrapSafe (node:internal/modules/cjs/loader:1055:15)

The error appeared dozens of times and prevented the build from completing.

Engineering Analysis

This was not a logic error in the application code.

Instead, it was an Interpreter Compatibility Conflict between the Node.js engine and the Windows environment.

What was happening internally?

• EAS Build calls internal Expo dependencies such as Metro configuration packages.
• These packages rely on modern JavaScript syntax.
• On Windows, Node.js failed to parse the "typeof" keyword inside the dependency source code.
• Node interpreted it as an unexpected token, even though the syntax was valid.

In short:

«The build system failed before even reaching my application code.»

Failed Troubleshooting Attempts

I exhausted nearly every common solution used by developers on Windows environments:

1️⃣ Removing Dependencies

• Deleted "node_modules"
• Deleted "package-lock.json"
❌ Result: Failed
Reason: The issue was not corrupted packages, but how the OS interpreted them.

2️⃣ Changing Node.js Versions

• Installed multiple LTS versions
❌ Result: Failed
Reason: The conflict originated from Windows shell environment variables and system-level parsing behavior.

3️⃣ Clearing npm Cache

npm cache clean --force

❌ Result: Failed
Reason: Temporary files were not responsible.

4️⃣ Updating Build Tools

• Updated EAS CLI
• Updated Expo CLI
❌ Result: Failed
Reason: Tooling was healthy — the OS environment was not.

5️⃣ Modifying Babel & App Configurations

• Edited "babel.config.js"
• Edited "app.json"
❌ Result: Failed
Reason: The error occurred before Babel was even invoked.

The Turning Point — Migrating to Linux

At this stage, Windows became a complete roadblock.

Instead of wasting more time, I made a strategic engineering decision:

«Move the entire development environment to a Unix-based system.»

Steps Taken:

✅ Installed VirtualBox
✅ Created a virtual machine running Ubuntu Linux
✅ Installed a fresh Node.js environment
✅ Reinstalled Expo and EAS CLI
✅ Cloned the same project files without modification

The Critical Test

Inside Linux, I ran the exact same command:

eas build --platform android --profile production

Result:

✅ The error disappeared immediately
✅ The build process started successfully
✅ No code changes were required
✅ No dependency changes were required

The exact same project that failed on Windows worked flawlessly on Linux.

Technical Explanation

Linux systems are Unix-based, which aligns with the native environment used to design Node.js and Expo tooling.

This provides:

• Consistent file path handling
• Stable environment variable management
• Reliable JavaScript engine behavior
• Better compatibility with modern build systems

Meanwhile, Windows introduced hidden interpreter conflicts that disrupted dependency parsing.

Key Lesson

Sometimes the problem is not in:

❌ Your code
❌ Your libraries
❌ Your build tools

But in the execution environment itself.

When facing persistent, unexplainable build errors:

«Changing the operating system may be the most efficient solution.»

الملخص

واجهت خطأ غريب أثناء بناء نسخة الإنتاج لتطبيقي باستخدام Expo.
التطبيق كان يعمل بشكل طبيعي في التطوير، لكن أثناء تنفيذ أمر بناء الأندرويد ظهر خطأ:

SyntaxError: Unexpected token 'typeof'

بعد تجربة جميع الحلول التقليدية على نظام Windows مثل حذف المكتبات وتحديث Node وتنظيف الكاش — استمرت المشكلة.

اتضح أن السبب لم يكن في الكود، بل في تعارض بيئة Windows مع طريقة تفسير Node.js للمكتبات الحديثة.

الحل كان بالانتقال إلى نظام Linux عبر جهاز وهمي Ubuntu.

بمجرد تشغيل نفس المشروع ونفس أمر البناء على Linux:
اختفى الخطأ فوراً ونجح البناء بدون أي تعديل.

الدرس المهم:

أحياناً بيئة التشغيل نفسها هي سبب المشكلة، وتغيير النظام قد يكون الحل الجذري.

DEV Community: Hala

Fixing a Prisma Client Resolution Issue in a pnpm Monorepo

Introduction

The Problem

Project Structure

Step 1: Check Prisma Versions

Step 2: Install Prisma Explicitly at the Workspace Root

Step 3: Generate Prisma Client Again

Verifying the Fix

A New Problem Appeared During the Build

The Remaining Build Errors

1. Workspace Package Resolution

2. Prisma Shutdown Hook

3. Prisma Module Import Path

4. Missing DTO

5. Prisma JSON Type

Redis / BullMQ Errors

Prisma Relation Errors

Delivery Query Error

Commission Rule Ordering Error

An Important Lesson

Dependency resolution

Generated-client / TypeScript issues

Final Prisma State

What Still Needs to Be Fixed

Useful Debugging Commands

Check package versions

Check the entire workspace

Install matching Prisma versions

Install workspace dependencies

Generate Prisma Client

Build the API

Conclusion

How to Fix Image Upload Failures & 404 Errors in React Native + Express/Multer

The Error Logs

1. Upload Phase Error (React Native Console)

2. Asset Rendering Phase Warning (Expo / LogBox)

Root Cause Analysis

Problem 1: Unhandled Missing Upload Directory (ENOENT)

Problem 2: Incorrect Static File Route Prefix

Problem 3: Android File URI Formatting

The Solution

1. Auto-create Directory in multer.js

2. Map Static Route Correctly in server.js

3. Handle Client-Side Uploads in React Native (functions.js)

Verification & Results

Conclusion

Fixing “Please update Expo Go” error (even when it’s already updated)

How Windows Caused a Fatal “typeof” Error in Expo EAS Build — And Why Linux Solved It

Problem 1: Unhandled Missing Upload Directory (`ENOENT`)

1. Auto-create Directory in `multer.js`

2. Map Static Route Correctly in `server.js`

3. Handle Client-Side Uploads in React Native (`functions.js`)