Prisma Postgres Adapter with Turborepo does not work

[SooditK]

Bug description

if I have a turborepo monorepo with a packages/db folder containing my prisma schema, and a apps/web application (Next.JS) and I use the updated prisma with previewFeatures = ["queryCompiler", "driverAdapters"]

I get an error:

web:dev: Error: ENOENT: no such file or directory, open '/MYPATH/MONOREPO/apps/web/generated/prisma/query_compiler_bg.wasm'
web:dev:     at Object.getQueryCompilerWasmModule (../../packages/db/generated/prisma/index.js:2534:70)
web:dev:     at eval (../../packages/db/generated/prisma/runtime/client.js:74:23092)
web:dev:   2532 |       getQueryCompilerWasmModule: async () => {
web:dev:   2533 |         const queryCompilerWasmFilePath = require('path').join(config.dirname, 'query_compiler_bg.wasm')
web:dev: > 2534 |         const queryCompilerWasmFileBytes = require('fs').readFileSync(queryCompilerWasmFilePath)
web:dev:        |                                                                      ^
web:dev:   2535 |
web:dev:   2536 |         return new WebAssembly.Module(queryCompilerWasmFileBytes)
web:dev:   2537 |       } {
web:dev:   errno: -2,
web:dev:   code: 'ENOENT',
web:dev:   syscall: 'open',
web:dev:   path: '/MYPATH/MONOREPO/apps/web/generated/prisma/query_compiler_bg.wasm'
web:dev: }

it is looking for query_compiler_bg.wasm at the web application but it should look for the same in the db package

before you ask if I am creating a new PrismaClient inside the web application, I'm not, I'm only creating one prisma client in db package and exporting it, which is getting used in all other apps

Severity

🚨 Critical: Data loss, app crash, security issue

Reproduction

Follow your guide to use prisma with turborepo and update the index.ts file to use the "Rust-free" version of Prisma ORM (using the queryCompiler and adapters), something you guys have mentioned here

Expected vs. Actual Behavior

let's call prisma with previewFeatures = ["queryCompiler", "driverAdapters"] to be p1 and prisma without previewFeatures = ["queryCompiler", "driverAdapters"] to be p2

I expect p1 and p2 to behave the same when I'm using them in a monorepo/turborepo

Frequency

Consistently reproducible

Does this occur in development or production?

Both development and production

Is this a regression?

if I directly use prisma without the previewFeatures = ["queryCompiler", "driverAdapters"], it works

Workaround

as I said

if I directly use prisma without the previewFeatures = ["queryCompiler", "driverAdapters"], it works

Prisma Schema & Queries

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["queryCompiler", "driverAdapters", "views"]
  output          = "../generated/prisma"
}

generator kysely {
  provider     = "prisma-kysely"
  output       = "../src/db"
  fileName     = "types.ts"
  enumFileName = "enums.ts"
}

model AuthSession {
  id        String   @id @unique
  userId    String
  expiresAt DateTime @map("expiresAt")
 
  @@map("auth_session")
}
// and rest of the models

import { PrismaPg } from "@prisma/adapter-pg";
import * as dotenv from "dotenv";
import { Kysely, PostgresAdapter, PostgresIntrospector, PostgresQueryCompiler } from "kysely";
import kyselyExtension from "prisma-extension-kysely";
import { PrismaClient as prismaClient } from "../generated/prisma";
import type { DB } from "./db/types";

import type { z } from "zod";
dotenv.config();

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
const prismaBase = new prismaClient({ adapter });

const p = prismaBase.$extends(
	kyselyExtension({
		kysely: (driver) =>
			new Kysely<DB>({
				dialect: {
					createDriver: () => driver,
					createAdapter: () => new PostgresAdapter(),
					createIntrospector: (db) => new PostgresIntrospector(db),
					createQueryCompiler: () => new PostgresQueryCompiler(),
				},
				plugins: [],
			}),
	})
);

const globalForPrisma = global as unknown as { prisma: typeof p };

const prisma = globalForPrisma.prisma || p;

if (process.env.NODE_ENV !== "production") {
	globalForPrisma.prisma = prisma;
}

export { prisma };
type PrismaClient = typeof prisma;
export type { PrismaClient };

Prisma Config

I tried with and without it, the results were same

import "dotenv/config";
import path from "node:path";
import type { PrismaConfig } from "prisma";

export default {
	earlyAccess: true,
	schema: path.join("prisma", "schema.prisma"),
} satisfies PrismaConfig;

Logs & Debug Info

I was not able to run any database queries as it was throwing the following error everytime, so I have attached this only, let me know if you need anything else

web:dev: Error: ENOENT: no such file or directory, open '/MYPATH/MONOREPO/apps/web/generated/prisma/query_compiler_bg.wasm'
web:dev:     at Object.getQueryCompilerWasmModule (../../packages/db/generated/prisma/index.js:2534:70)
web:dev:     at eval (../../packages/db/generated/prisma/runtime/client.js:74:23092)
web:dev:   2532 |       getQueryCompilerWasmModule: async () => {
web:dev:   2533 |         const queryCompilerWasmFilePath = require('path').join(config.dirname, 'query_compiler_bg.wasm')
web:dev: > 2534 |         const queryCompilerWasmFileBytes = require('fs').readFileSync(queryCompilerWasmFilePath)
web:dev:        |                                                                      ^
web:dev:   2535 |
web:dev:   2536 |         return new WebAssembly.Module(queryCompilerWasmFileBytes)
web:dev:   2537 |       } {
web:dev:   errno: -2,
web:dev:   code: 'ENOENT',
web:dev:   syscall: 'open',
web:dev:   path: '/MYPATH/MONOREPO/apps/web/generated/prisma/query_compiler_bg.wasm'
web:dev: }

Environment & Setup

• OS: macOS
• Database: PostgreSQL
• Node.js version: 20.11.1

Prisma Version

6.7.0

"@prisma/client": "^6.7.0",
"@prisma/adapter-pg": "^6.7.0"

[sajadmh]

I am experiencing this exact issue with an identical setup (repo/database, turborepo, queryCompiler, generated output in src/generated/prisma).

ENOENT: no such file or directory, open '/path/apps/web/src/generated/prisma/query_compiler_bg.wasm'
at Jn.handleRequestError (../../packages/database/src/generated/prisma/runtime/client.js:84:7458)

The directory it's looking at is an app in the monorepo outside of the database package.

[iamnafets]

Same issue, unfortunately a blocker!

[yungkittty]

same here, deploying on vercel but i'm using a yarn monorepo

[LZL0]

Same.

[LZL0]

Issue still present on 6.8.0-dev.46.

[Bewinxed]

had this issue when switching from normal client to driverAdapter.

fixed by

bun r @prisma/client
bun i @prisma/client -f

bunx prisma generate
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma

✔ Generated Prisma Client (v6.8.2) to ./node_modules/@prisma/client in 31ms

Start by importing your Prisma Client (See: https://pris.ly/d/importing-client)

Tip: Want to turn off tips and other hints? https://pris.ly/tip-4-nohints``

[Sexual]

Any updates on this issue now that 6.9.0 is released? I've tested it and it's still a blocker

[eredzik]

As a workaround I found that in monorepo this issue is caused by generated client index.js file that contains

  config.dirname = path.join(process.cwd(), alternativePath)`.

Changing this line manually in generated code to resolves the issue and it works in dev mode

config.dirname = path.join('/path/to/monorepo', alternativePath)

In my case prisma generated package was in /packages/db/generated/prisma-client while app using it was under /someapp and it incorrectly resolved root path in repository

[Sexual]

As a workaround I found that in monorepo this issue is caused by generated client index.js file that contains

  config.dirname = path.join(process.cwd(), alternativePath)`.

Changing this line manually in generated code to resolves the issue and it works in dev mode

config.dirname = path.join('/path/to/monorepo', alternativePath)

In my case prisma generated package was in /packages/db/generated/prisma-client while app using it was under /someapp and it incorrectly resolved root path in repository

I looked through the code as well and came to that conclusion, but it's counter productive as the generated code is happening during the build process.

[PILLOWPET]

Same issue on my side tested it in 6.9.0 the wasm file is not included in the build output for some reason.

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["relationJoins", "queryCompiler", "driverAdapters"]
  output          = "../src/@db-client"
}

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
});

export const prisma =
  globalForPrisma.prisma ??
  new PrismaClient({
    log: ['info', 'warn', 'error'],
    adapter,
  });

ENOENT: no such file or directory, open '/var/task/frontend/next-app/src/@db-client/query_compiler_bg.wasm'

This works locally but not on Vercel, I have no idea why

[nurul3101]

I am able to reproduce this issue with Prisma 6.9.0

The error doesn't occur if we remove the previewFeatures - ["queryCompiler", "driverAdapters"]

[IHIutch]

The problem is, for me anyway, that I've been trying to use queryCompiler as a workaround for this issue https://github.com/prisma/prisma/discussions/19498

[aqrln]

Hey folks, there are two possible workarounds for you right now, choose whichever you prefer:

1. You can remove the output path in you generator config and import the generated client from @prisma/client.
2. You can try using the new prisma-client generator instead of prisma-client-js. It's currently in Early Access and we are working on bringing it to Preview.

[IHIutch]

Hmm, these don't seem to work for me :(

Heres a copy of my current project: https://github.com/IHIutch/gtm-prisma-6.9.0-repro

I'm using

 '@prisma/adapter-pg': ^6.9.0
 '@prisma/client': ^6.9.0
 '@tanstack/react-start': ^1.121.0-alpha.26
  prisma: ^6.9.0
  turbo: ^2.5.4
  typescript: ^5.7.2
  vite: ^6.3.5

@prisma/client

Here's what I get if I use @prisma/client:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["relationJoins"]
}

The build succeeds, but I get this error at runtime

TypeError [ERR_INVALID_MODULE_SPECIFIER]: Invalid module ".prisma/client/default" is not a valid package name imported from /var/task/chunks/_/ssr.mjs
    at parsePackageName (node:internal/modules/package_json_reader:222:11)
    ... 8 lines matching cause stack trace ...
    at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:305:38) {

---

prisma-client with output

If I try prisma-client, I get

generator client {
  provider        = "prisma-client"
  output          = "../generated/prisma"
  previewFeatures = ["relationJoins"]
}

The build succeeds, not immediate errors, but when I execute a Prisma query I get this error:

Unhandled Rejection: PrismaClientInitializationError: Prisma Client could not locate the Query Engine for runtime "rhel-openssl-3.0.x".

This is likely caused by a bundler that has not copied "libquery_engine-rhel-openssl-3.0.x.so.node" next to the resulting bundle.

---

PG Adapter with linked dependency

Since I'm not using Next.js, I'm not using [@prisma/nextjs-monorepo-workaround-plugin] (https://www.npmjs.com/package/@prisma/nextjs-monorepo-workaround-plugin). Instead, I tried the Postgres Adapter.

That brings me back to the Postgres Adapter.

I actually hadn't seen this guidance until just now:

But that led to this build error:

gtm-start:build: error during build:
gtm-start:build: [vite]: Rollup failed to resolve import "db" from "/vercel/path0/packages/database/src/index.ts".
gtm-start:build: This is most likely unintended because it can break your application at runtime.
gtm-start:build: If you do want to externalize this module explicitly add it to
gtm-start:build: `build.rollupOptions.external`

---

PG Adapter with relative import

Prior to that, I was using a relative path, which again, did allow the build to succeed, when when executing Prisma cause this error (perhaps expectedly?):

Unhandled Rejection: Error: Cannot find module '@prisma/client/runtime/query_compiler_bg.postgresql.wasm'

---

For what its worth, for me anyway, trying to follow several of the guides has been tricky because there are different approaches for each. It's not clear if its me who set my project up incorrectly or if/where there's an issue with Prisma. I know there are a lot of changes currently in progress (very much looking forward to the updates) but that's made following the guidance a bit difficult. Here are a few pages I've been bouncing between:

• https://www.prisma.io/docs/guides/turborepo
• https://www.prisma.io/docs/guides/tanstack-start
• https://www.prisma.io/docs/orm/prisma-client/deployment/serverless/deploy-to-vercel#deploying-prisma-in-monorepos-on-vercel
• https://www.prisma.io/docs/orm/prisma-schema/overview/generators

---

Some updates:

I'm using turborepo with pnpm, someone in discord suggested creating .npmrc and adding public-hoist-pattern[]=*prisma*.

That seemed to work if I'm not using the PG Adapter. However, after updating Prisma to 6.10.1, I started getting the rhel-openssl-3.0.x issue again. Tried downgrading and continued to get the same issue.

Then I switched from prisma-client to prisma-client-js and importing PrismaClient from ./generated/prisma to @prisma/client. That is now working. Then, as an experiment, I switched back to prisma-client and everything is still working. 🤷 Anyway, I'm leaving it for now.

One thing to note: v6.10 appears to remove the index.ts from generated, which adds another difference from the guides above. If you're using output = './generate/prisma' you'll need to import PrismaClient from './generated/prisma/client'.

[LZL0]

@IHIutch Remove the pg adapter in the Prisma client and make sure that your schema looks like this:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["relationJoins"]
}

For the rust-based engine you can't have an adapter and don't need an output path. Turborepos don't work with the new JavaScript engine yet.

[LZL0]

Hey folks, there are two possible workarounds for you right now, choose whichever you prefer:

1. You can remove the output path in you generator config and import the generated client from @prisma/client.
2. You can try using the new prisma-client generator instead of prisma-client-js. It's currently in Early Access and we are working on bringing it to Preview.

Method 1 will cause the dev server to work, the build to succeed, but it will fail in production (just like in OP's case).

Unhandled Rejection: [Error: ENOENT: no such file or directory, open '/var/task/node_modules/.prisma/client/query_compiler_bg.wasm'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/var/task/node_modules/.prisma/client/query_compiler_bg.wasm'
}

Method 2 will work in development, but will fail to build due to a webpack bug.

next:build:    Collecting page data ...
next:build: TypeError: t is not a function
next:build:     at Object.getQueryCompilerWasmModule (.next/server/chunks/7443.js:1:218820)
next:build: TypeError: t is not a function
next:build:     at Object.getQueryCompilerWasmModule (.next/server/chunks/7443.js:1:218820)
next:build: TypeError: t is not a function
next:build:     at Object.getQueryCompilerWasmModule (.next/server/chunks/7443.js:1:218820)
next:build: prisma:error t is not a function
next:build: TypeError: t is not a function
next:build:     at Object.getQueryCompilerWasmModule (.next/server/chunks/7443.js:1:218820) {
next:build:   clientVersion: '6.10.1'
next:build: }

[Bouhtouch]

I'm having the same issue as OP, and I'm "wrapping" prisma in a module that we share across all our app and services.

Using @prisma/client instead of custom output unfortunately is not an option as our app and services need to have only our wrapper as dependency, and the generated client need to be under it.

Using prisma-client too is not an option as it's a regression compared to prisma-client-js when looking at the types generated, many model collumn types are lost resulting in a pletora of any (lint) errors.

[nirtamir2]

I have the same issue as @IHIutch https://github.com/prisma/prisma/issues/27083#issuecomment-2980748717

import { PrismaPg } from '@prisma/adapter-pg'
import { PrismaClient } from './generated/client.js'

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });

export const prisma = new PrismaClient({ adapter });

and

generator client {
  provider        = "prisma-client"
  output          = "../generated"
  previewFeatures = ["driverAdapters", "queryCompiler"]
  moduleFormat    = "esm"
}

Edit:

It work with .npmrc

public-hoist-pattern[]=*prisma*

And

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

and

import { PrismaClient } from '@prisma/client'

export const prisma = new PrismaClient();

Thank you @IHIutch 🙏

[IHIutch]

Looks like there is an issue with Prisma and vite-tsconfig-paths. Since I'm using TanStack Start, which uses Vite, that was the issue I was having. I was able to get things working thanks to a solution in this thread

[jkomyno]

We now have a working example of @prisma/adapter-pg + Next.js + Turborepo here (it should get merged in main next Monday, see https://github.com/prisma/prisma-examples/pull/8243).

We expect Turborepo to work out of the box in Prisma 6.12.0 (expected to be released on July 15th).

[LZL0]

⨯ Error [PrismaClientKnownRequestError]: 
Invalid `prisma.trade_ideas.findMany()` invocation:


ENOENT: no such file or directory, open '/var/task/node_modules/.prisma/client/query_compiler_bg.wasm'

Same issue with version 6.12

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["driverAdapters", "queryCompiler"]
}

[toby-palau]

Hey @jkomyno , just saw release 6.12.0 went public and ran a quick test. Unfortunately I'm still getting the same error when trying to run it on Vercel :(

Invalid `prisma.account.findUnique()` invocation:


ENOENT: no such file or directory, open '/var/task/generated/prisma/query_compiler_bg.wasm'
    at ow.handleRequestError (.next/server/chunks/980.js:74:7989)
    at ow.handleAndLogRequestError (.next/server/chunks/980.js:74:7049)
    at ow.request (.next/server/chunks/980.js:74:6756)
    at async a (.next/server/chunks/980.js:86:7682)
    at async k (.next/server/chunks/980.js:721:60198)
    at async m (.next/server/app/reports/page.js:1:17004) {
  code: 'ENOENT',
  clientVersion: '6.12.0',
  meta: [Object],
  digest: '402403822'
}

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["queryCompiler", "driverAdapters"]
  output          = "../generated/prisma"
}

[Sexual]

I can confirm this is still not working with the latest release

[jkomyno]

@LZL0, @toby-palau, @Sexual, did you all re-run prisma generate after installing the new version of prisma and @prisma/client?

Can you please share a minimal reproduction of your project, so we can debug it please? Thanks.

[LZL0]

@LZL0, @toby-palau, @Sexual, did you all re-run prisma generate after installing the new version of prisma and @prisma/client?

Can you please share a minimal reproduction of your project, so we can debug it please? Thanks.

Yes, I have it as a post-install step. Now that the client is moving to a directory, I will have to run a script emptying that directory before the postinstall step. Since having Prisma client generation run in postinstall might be the best practice, @jkomyno I don't know if Prisma should remove the generated client if it exists before the generation step.

[foyarash]

Hello everyone,

I encountered this issue aswell, and spent the day without being able to fix the issue. However, I managed to be able to see the wasm binaries in the vercel source, which wasnt the case before. What I needed to do was to add the following in the next config :

outputFileTracingIncludes: {
    "**": [
      path
        .join(prismaClientRequire, "runtime/*.postgresql.wasm")
        .replace("../", ""),
    ],
  },

where prismaClientRequire is

const _require = createRequire(import.meta.url);
const prismaClientRequire = path.relative(
  fileURLToPath(import.meta.url),
  path.dirname(_require.resolve("@prisma/client"))
);

After this, I'm able to see the WASM binaries in the correct path in the source of my deployment. But yeah I still get the error saying that the binary is not found, which is weird.

I don't know if that can help things moving in the right direction, but I'll keep digging. Hope this can help

[catdad]

Just curious, since it's wasm, why not embed the binary into the js file instead of writing a separate file to disk and then expecting to find it in a different location?

[toby-palau]

@jkomyno Thanks for looking into this.

I created this quick minimal reproducible example. It's a simple create-next-app with a single page. When I deploy this to Vercel, the build process is successful, but when I access the page I get the same run-time error (see below) and all calls to server actions that call the prisma client are failing with status 500.

In my build logs (see below) you can see that the prisma client is generated successfully.

My suspicion is that the .wasm file is not properly instantiated when the prisma client is called from a server action specifically. Hope that helps.

Note that in order to deploy this project, you'll have to include an env variable DATABASE_URL with a valid Postgres database url. https://github.com/toby-palau/minimal-reprod-wasm-query-compiler

Run-time error

Error [PrismaClientKnownRequestError]: 
Invalid `prisma.user.findUnique()` invocation:


ENOENT: no such file or directory, open '/var/task/generated/prisma/query_compiler_bg.wasm'
    at hm.handleRequestError (.next/server/app/page.js:86:8027)
    at hm.handleAndLogRequestError (.next/server/app/page.js:86:7087)
    at hm.request (.next/server/app/page.js:86:6794)
    at async f (.next/server/app/page.js:98:7682)
    at async m (.next/server/app/page.js:6:1566) {
  code: 'ENOENT',
  clientVersion: '6.12.0',
  meta: [Object],
  digest: '1247282292'
}

Build logs

[09:39:36.401] Running build in Washington, D.C., USA (East) – iad1
[09:39:36.401] Build machine configuration: 4 cores, 8 GB
[09:39:36.419] Cloning github.com/toby-palau/minimal-reprod-wasm-query-compiler (Branch: main, Commit: f61ea18)
[09:39:36.661] Cloning completed: 242.000ms
[09:39:39.120] Restored build cache from previous deployment (DwGNfNHFh3F9AaYSp1m7bWyeqJEy)
[09:39:41.027] Running "vercel build"
[09:39:41.513] Vercel CLI 44.3.0
[09:39:41.799] Installing dependencies...
[09:39:43.088] 
[09:39:43.088] > [email protected] postinstall
[09:39:43.088] > prisma generate
[09:39:43.089] 
[09:39:43.837] Prisma schema loaded from prisma/schema.prisma
[09:39:43.928] 
[09:39:43.929] ✔ Generated Prisma Client (v6.12.0) to ./generated/prisma in 59ms
[09:39:43.929] 
[09:39:43.929] Start by importing your Prisma Client (See: https://pris.ly/d/importing-client)
[09:39:43.929] 
[09:39:43.929] Tip: Want to turn off tips and other hints? https://pris.ly/tip-4-nohints
[09:39:43.929] 
[09:39:43.948] 
[09:39:43.948] up to date in 2s
[09:39:43.948] 
[09:39:43.948] 134 packages are looking for funding
[09:39:43.948]   run `npm fund` for details
[09:39:43.981] Detected Next.js version: 15.4.1
[09:39:43.984] Running "npm run vercel-build"
[09:39:44.097] 
[09:39:44.098] > [email protected] vercel-build
[09:39:44.098] > prisma generate && prisma migrate deploy && next build
[09:39:44.098] 
[09:39:44.726] Prisma schema loaded from prisma/schema.prisma
[09:39:44.817] 
[09:39:44.818] ✔ Generated Prisma Client (v6.12.0) to ./generated/prisma in 46ms
[09:39:44.818] 
[09:39:44.818] Start by importing your Prisma Client (See: https://pris.ly/d/importing-client)
[09:39:44.818] 
[09:39:44.818] Tip: Want to turn off tips and other hints? https://pris.ly/tip-4-nohints
[09:39:44.818] 
[09:39:45.438] Prisma schema loaded from prisma/schema.prisma
[09:39:45.440] Datasource "db": PostgreSQL database "neondb", schema "public" at "***"
[09:39:46.574] 
[09:39:46.575] 1 migration found in prisma/migrations
[09:39:46.575] 
[09:39:48.125] 
[09:39:48.125] No pending migrations to apply.
[09:39:49.339]    ▲ Next.js 15.4.1
[09:39:49.340] 
[09:39:49.367]    Creating an optimized production build ...
[09:39:57.645]  ✓ Compiled successfully in 5.0s
[09:39:57.649]    Linting and checking validity of types ...
[09:40:00.779]    Collecting page data ...
[09:40:02.308]    Generating static pages (0/5) ...
[09:40:03.130]    Generating static pages (1/5) 
[09:40:03.130]    Generating static pages (2/5) 
[09:40:03.131]    Generating static pages (3/5) 
[09:40:03.131]  ✓ Generating static pages (5/5)
[09:40:03.575]    Finalizing page optimization ...
[09:40:03.575]    Collecting build traces ...
[09:40:09.743] 
[09:40:09.755] Route (app)                                 Size  First Load JS
[09:40:09.755] ┌ ○ /                                    6.57 kB         106 kB
[09:40:09.756] └ ○ /_not-found                            989 B         101 kB
[09:40:09.756] + First Load JS shared by all            99.8 kB
[09:40:09.756]   ├ chunks/4bd1b696-cf72ae8a39fa05aa.js  54.1 kB
[09:40:09.756]   ├ chunks/964-ffe52c201db533c6.js       43.7 kB
[09:40:09.756]   └ other shared chunks (total)          1.94 kB
[09:40:09.756] 
[09:40:09.756] 
[09:40:09.756] ○  (Static)  prerendered as static content
[09:40:09.756] 
[09:40:09.890] Traced Next.js server files in: 83.153ms
[09:40:10.000] Created all serverless functions in: 110.042ms
[09:40:10.019] Collected static files (public/, static/, .next/static): 12.355ms
[09:40:10.066] Build Completed in /vercel/output [28s]
[09:40:10.113] Deploying outputs...
[09:40:16.447] 
[09:40:16.594] Deployment completed
[09:40:27.041] Uploading build cache [188.84 MB]...
[09:40:30.317] Build cache uploaded: 3.277s
[09:40:32.522] Exiting build container

[foyarash]

Hello everyone,

I found a solution that feels VERY HACKY but, in my case, worked.

I needed to edit the generated internal/class.ts file thats generated, and update the content of the getQueryCompilerWasmModule

getQueryCompilerWasmModule: async () => {
    const dynamicRequireFn = async <const T extends string>(name: T) =>
      typeof globalThis.__non_webpack_require__ === 'function'
        ? Promise.resolve(globalThis.__non_webpack_require__(name))
        : await import(/* webpackIgnore: true */ /* @vite-ignore */ name)

    // Note: we must use dynamic imports here to avoid bundling errors like `Module parse failed: Unexpected character '' (1:0)`.
    const { readFile } = await dynamicRequireFn('node:fs/promises')
    const { join } = await dynamicRequireFn('node:path')
    const { createRequire } = await dynamicRequireFn('node:module')
    const _require = createRequire(import.meta.url)

    // THE MAGIC HAPPENS HERE
    const wasmModulePath = _require.resolve(join(process.cwd(), "node_modules/@prisma/client/runtime/query_compiler_bg.postgresql.wasm"))
    const wasmModuleBytes = await readFile(wasmModulePath)

    return new globalThis.WebAssembly.Module(wasmModuleBytes)

This made the error gone, but again, feels very hacky

[LZL0]

Just curious, since it's wasm, why not embed the binary into the js file instead of writing a separate file to disk and then expecting to find it in a different location?

I believe this might be the best solution.