Prisma Client doesn't work outside of node_modules when using custom output dir

[dan2kx]

Bug description

Im trying to create an nx environment using next and i need multiple prisma clients, one for each application. I have added the output parameter to the schema file and can generate the prisma client without issue.

When I try and use the prisma client to serve data through my API it gives an error:

 Query engine exited with code 101 
thread 'main' panicked at 'Could not open datamodel file "/app/dist/apps/main/.next/server/pages/api/schema.prisma"', query-engine/query-engine/src/opt.rs:196:53
stack backtrace:
0: rust_begin_unwind at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
1: std::panicking::begin_panic_fmt at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:435:5
2: query_engine::opt::load_datamodel_file::{{closure}}
3: structopt::StructOpt::from_args
4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
5: std::thread::local::LocalKey<T>::with
6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
7: async_io::driver::block_on
8: std::thread::local::LocalKey<T>::with
9: std::thread::local::LocalKey<T>::with
10: async_std::task::builder::Builder::blocking
11: query_engine::main

it looks like it trying to access the prisma files relative to the api file that is being called. the client works fine if i remove the custom output dir and build it to the default @prisma/client directory in node_modules.

How to reproduce

Create a prisma schema with a custom output directory
import the prisma client from the new directory
run the api and see the error on the server console

Expected behavior

No response

Prisma information

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

generator client {
  provider      = "prisma-client-js"
  output        = "client"
  binaryTargets = ["native", "linux-musl"]
}

model ...

Environment & setup

• OS: macOS
• Database: MySQL
• Node.js version: 14.17.3

Prisma Version

prisma               : 2.27.0
@prisma/client       : 2.27.0
Current platform     : darwin
Query Engine         : query-engine cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : cdba6ec525e0213cce26f8e4bb23cf556d1479bb
Studio               : 0.410.0

[pantharshit00]

Hello @dan2kx

I wasn't able to reproduce this. Can you please share your exact folder structure? It would be even better if you can share a reproduction inside of a git repository.

[dan2kx]

Hi @pantharshit00, thanks for getting back to me. I've created a basic implementation which replicates my issue here.

There is a single app in the /apps folder which is a Next JS app, with a single endpoint /api/products, and that is calling my prisma client library found in /libs/db.

You can bring the app up by running npx nx run app:serve in a terminal, my client uses the DATABASE_URL env and I'm sure you will already have a database you can use for this but just in case you can build out a db in docker, there is a makefile command make up which you can use with the env variable: DATABASE_URL="mysql://root:password@localhost:33006/db"

If you navigate to http://localhost:4200/api/products which should be where it serves, you will see the first problem I had:

Module not found: Can't resolve '_http_common'
  25628 | var require_http_parser = __commonJS2((exports2, module2) => {
  25629 |   "use strict";
> 25630 |   var common = require("_http_common");
        |               ^
  25631 |   if (common.HTTPParser) {
  25632 |     module2.exports = common.HTTPParser;
  25633 |   } else {

I found two solutions to resolve that error, I'm not really sure why that's an issue, but if you look at the next.config.js file in apps/app you can see two removed webpack functions, either one will resolve that error and lead you to the next error which is where I got completely stuck...

PrismaClientInitializationError2 [PrismaClientInitializationError]: 
Invalid `prisma.product.findMany()` invocation:


  Query engine exited with code 101

thread 'main' panicked at 'Could not open datamodel file "...root/nx-prisma/dist/apps/app/.next/server/pages/api/schema.prisma"', query-engine/query-engine/src/opt.rs:196:53
stack backtrace:
   0: _rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: query_engine::opt::load_datamodel_file::{{closure}}
   3: structopt::StructOpt::from_args
   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   5: std::thread::local::LocalKey<T>::with
   6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   7: async_io::driver::block_on
   8: std::thread::local::LocalKey<T>::with
   9: std::thread::local::LocalKey<T>::with
  10: async_std::task::builder::Builder::blocking
  11: query_engine::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
    at cb (webpack-internal:///../../libs/db/src/lib/client/runtime/index.js:392:539)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async apiHandler (webpack-internal:///./pages/api/products.ts:8:20)
    at async apiResolver (...root/nx-prisma/node_modules/next/dist/next-server/server/api-utils.js:8:1)
    at async DevServer.handleApiRequest (...root/nx-prisma/node_modules/next/dist/next-server/server/next-server.js:66:462)
    at async Object.fn (...root/nx-prisma/node_modules/next/dist/next-server/server/next-server.js:58:580)
    at async Router.execute (...root/nx-prisma/node_modules/next/dist/next-server/server/router.js:25:67)
    at async DevServer.run (...root/nx-prisma/node_modules/next/dist/next-server/server/next-server.js:68:1042)
    at async DevServer.handleRequest (...root/nx-prisma/node_modules/next/dist/next-server/server/next-server.js:32:504) {
  clientVersion: '2.27.0',
  errorCode: undefined
}

Thanks for the help and please let me know if you need anything else from me.

[pantharshit00]

This is actually related to #6564 and you will need to wait for #7931 to be merged.

[hugbubby]

This is actually related to #6564 and you will need to wait for #7931 to be merged.

ETA?

[hugbubby]

Bug description

Im trying to create an nx environment using next and i need multiple prisma clients, one for each application. I have added the output parameter to the schema file and can generate the prisma client without issue.

When I try and use the prisma client to serve data through my API it gives an error:

 Query engine exited with code 101 
thread 'main' panicked at 'Could not open datamodel file "/app/dist/apps/main/.next/server/pages/api/schema.prisma"', query-engine/query-engine/src/opt.rs:196:53
stack backtrace:
0: rust_begin_unwind at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
1: std::panicking::begin_panic_fmt at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:435:5
2: query_engine::opt::load_datamodel_file::{{closure}}
3: structopt::StructOpt::from_args
4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
5: std::thread::local::LocalKey<T>::with
6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
7: async_io::driver::block_on
8: std::thread::local::LocalKey<T>::with
9: std::thread::local::LocalKey<T>::with
10: async_std::task::builder::Builder::blocking
11: query_engine::main

it looks like it trying to access the prisma files relative to the api file that is being called. the client works fine if i remove the custom output dir and build it to the default @prisma/client directory in node_modules.

How to reproduce

Create a prisma schema with a custom output directory
import the prisma client from the new directory
run the api and see the error on the server console

Expected behavior

No response

Prisma information

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

generator client {
  provider      = "prisma-client-js"
  output        = "client"
  binaryTargets = ["native", "linux-musl"]
}

model ...

Environment & setup

* OS: macOS

* Database: MySQL

* Node.js version: 14.17.3

Prisma Version

prisma               : 2.27.0
@prisma/client       : 2.27.0
Current platform     : darwin
Query Engine         : query-engine cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : cdba6ec525e0213cce26f8e4bb23cf556d1479bb
Studio               : 0.410.0

I'm not sure if you realize this but you can just name the client @prisma/custom-client, if the reason you're outputting it to a different directory is because of naming conflicts like the rest of us

[hugbubby]

Bug description

Im trying to create an nx environment using next and i need multiple prisma clients, one for each application. I have added the output parameter to the schema file and can generate the prisma client without issue.
When I try and use the prisma client to serve data through my API it gives an error:

 Query engine exited with code 101 
thread 'main' panicked at 'Could not open datamodel file "/app/dist/apps/main/.next/server/pages/api/schema.prisma"', query-engine/query-engine/src/opt.rs:196:53
stack backtrace:
0: rust_begin_unwind at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
1: std::panicking::begin_panic_fmt at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:435:5
2: query_engine::opt::load_datamodel_file::{{closure}}
3: structopt::StructOpt::from_args
4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
5: std::thread::local::LocalKey<T>::with
6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
7: async_io::driver::block_on
8: std::thread::local::LocalKey<T>::with
9: std::thread::local::LocalKey<T>::with
10: async_std::task::builder::Builder::blocking
11: query_engine::main

it looks like it trying to access the prisma files relative to the api file that is being called. the client works fine if i remove the custom output dir and build it to the default @prisma/client directory in node_modules.

How to reproduce

Create a prisma schema with a custom output directory
import the prisma client from the new directory
run the api and see the error on the server console

Expected behavior

No response

Prisma information

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

generator client {
  provider      = "prisma-client-js"
  output        = "client"
  binaryTargets = ["native", "linux-musl"]
}

model ...

Environment & setup

* OS: macOS

* Database: MySQL

* Node.js version: 14.17.3

Prisma Version

prisma               : 2.27.0
@prisma/client       : 2.27.0
Current platform     : darwin
Query Engine         : query-engine cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : cdba6ec525e0213cce26f8e4bb23cf556d1479bb
Studio               : 0.410.0

I'm not sure if you realize this but you can just name the client @prisma/custom-client, if the reason you're outputting it to a different directory is because of naming conflicts like the rest of us

Tried to make this work for a while actually; it caused Prisma's promise chains to stop working. As in, prisma.create({...}).catch().then() would throw an "undefined" error, as the .catch() value became undefined. So there's that.

[pantharshit00]

No ETA right now sadly. Undici v4 ships a wasm module and we need to verify its implications first.

[strothj]

I'm using Next.js with Yarn PnP (Yarn v3). I'm currently emitting the Prisma client in another package in my monorepo.

This probably won't help everyone but I thought I would leave this here in case it helps someone.

I added a post install script to my Prisma client package which patches index.js to set the dirname as follows:

const dirname = path.join(
  path.dirname(require.resolve("@oak/prisma-client/package.json")),
  "dist",
);

In this case @oak/prisma-client is the package with the generated client. It's own post install script is triggered after Prisma's.

[Frankitch]

@strothj could you please tell me what is the index.js you're talking about? There are many of them in the @prisma/client package!

[lucasbogerd]

I noticed that the depency has been updated and merged 13 days ago here. Does that mean this issue can be fixed? I'm currently unable to use two different databases (one MySQL and one MSSQL) and would prefer to not have to split up the project.

Alternatively: anybody know of a workaround to allow me to still use two databases in the same NextJS application? I'm trying to follow the comments here and here but am currently unable to generate two different clients.

edit: just found this issue, my app is unfortunately not fixed by changing the names (I did not use plain 'client' anywhere but checked regardless).

2nd edit: version 3.12.0 - released ~45 min after I posted this - has fixed the issue! 🥳

[janpio]

Is anyone still having this problem? This should be fixed for good now.

[pantharshit00]

I am going to close this as its been 3 months now and there is no activity here.

Please reply if you want us to take another look.