Generated client with custom path containing string client: ENOENT: no such file or directory, open 'D:\<projectpath>\node_modules\.prisma\client\schema.prisma

[TheVoid-0]

Bug description

Hello, i've commented on #10512 and told to create a new issue.

I tried creating a client in a custom path with the @prisma/client@dev but when loading the created client it throws
ENOENT: no such file or directory, open 'D:\development\<project-workspace>\node_modules\.prisma\client\schema.prisma'.

this is the schema used to generate the client

generator client {
  provider        = "prisma-client-js"
  output          = "./client"
  previewFeatures = ["interactiveTransactions"]
  binaryTargets = ["linux-musl", "darwin", "windows"]
}

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

I use this to generate a npm private library because I need multiple prisma clients with different schemas, so I import each of them from the corresponding library:

const client1 = await import('@myorg/prisma1').PrismaClient
const client2 = await import('@myorg/prisma2').PrismaClient

const prismaClient1 = new client({ datasources: { db: { url: this.prepareUrl(factoryOptions) } } })

But upon instantiating any one of them it produces that ENOENT error.

The libraries I mentioned have the following folder structure when installed in the consuming project:

inside node_modules/@myorg:

How to reproduce

• generate a prisma client with a custom path on a separate directory.
• Install the directory as a dependency on another project
• Load the generated client from the custom directory into the project
• Instantiate the client

Expected behavior

It would be expected the generated client to be capable of loading the runtime and prisma.schema from within it's own directory when an output path is specified on the .schema

Prisma information

generator client {
  provider        = "prisma-client-js"
  output          = "./client"
  previewFeatures = ["interactiveTransactions"]
  binaryTargets = ["linux-musl", "darwin", "windows"]
}

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

Environment & setup

• OS: windows
• Database: mysql
• Node.js version: 16

Prisma Version

prisma                  : 3.13.0-dev.3
@prisma/client          : 3.13.0-dev.3
Current platform        : windows
Query Engine (Node-API) : libquery-engine ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : ba8e3c2c2615e6af9303b3930e7de9377999a0e7
Studio                  : 0.459.0

ALSO TRIED WITH

Environment variables loaded from .env
prisma                  : 3.12.0
@prisma/client          : 3.12.0
Current platform        : windows
Query Engine (Node-API) : libquery-engine 22b822189f46ef0dc5c5b503368d1bee01213980 (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt ba8e3c2c2615e6af9303b3930e7de9377999a0e7 (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : 22b822189f46ef0dc5c5b503368d1bee01213980
Studio                  : 0.459.0

[janpio]

Can you try to use the generated Prisma Clients directly?
How do you go from that generated folder to the private library?

[TheVoid-0]

Thanks for the answer.

What do you mean by directly? generating and using the generated client directly on the application that's supposed to use prisma? I could do that, but that's exactly the burden we are trying to avoid. If every application needs to generate the client, this means we need to keep several .schemas in sync at each change, and also update each Dockerfile or build scripts whatsoever to generate the clients on each build for every application as well. If that's not what you mean, please let me know.

About the private library, that screenshot I showed about @myorg/prisma-geral is the whole library, on the library itself I have the dependencies on the @prisma/client and prisma cli to generate the client on a custom path based on the schema, this outputs that lib/ that can be seen on the screenshot. Then the library can be added normally with yarn add @myorg/prisma-geral, that will point to the index.d.ts and index.js inside lib/client that is the generated client.

This is the package.json of the library:

{
  "name": "@myorg/prisma-geral",
  "version": "1.0.0",
  "description": "add description",
  "types": "lib/client/index.d.ts",
  "main": "lib/client/index.js",
  "files": [
    "lib/*.js",
    "lib/*.ts",
    "lib/**/*.js",
    "lib/**/*.ts",
    "lib/*.prisma"
  ],
  "scripts": {
    "build": "npx prisma db pull --schema=lib/schema.prisma && rimraf lib/client && prisma generate --schema=lib/schema.prisma",
    "pre:publish": "rimraf ./lib/client && npx prisma generate --schema=lib/schema.prisma && yarn publish",
    "test": "jest"
  },
  "dependencies": {
    "@prisma/client": "^3.12.0"
  },
  "devDependencies": {
    "@types/node": "^17.0.22",
    "prettier": "^2.3.2",
    "prisma": "^3.12.0",
    "rimraf": "^3.0.2"
  },
  "license": "ISC"
}

I was trying to reproduce the issue on a smaller repository and made it work by accident while installing the libraries locally i.e npm i ../path-to-library wich results in a dependency with "@myorg/prisma-geral": "file: ../path-to-library, however, once published it sopped working again, i'm still trying to get more info on what happens

[janpio]

What do you mean by directly? generating and using the generated client directly on the application that's supposed to use prisma? I could do that, but that's exactly the burden we are trying to avoid. If every application needs to generate the client, this means we need to keep several .schemas in sync at each change, and also update each Dockerfile or build scripts whatsoever to generate the clients on each build for every application as well. If that's not what you mean, please let me know.

Sorry, should have elaborated. I meant:
Can you try to use the generated Prisma Clients directly to confirm that it is generated correctly and should work, and the problem is only introduced in the further process of putting it into a package and using it via that? Thanks.

[TheVoid-0]

I said before that I've made it work by accident but I guess I was dreaming, could not make it work again anyway, here is a reproducible example https://github.com/TheVoid-0/issue-prisma-enoent-schema.prisma if someone could aid me with some insights. I do not know what exactly prisma would need to work in a package, I've assumed that as long as it had it's client it would work, maybe I'm missing something simple?

@janpio thanks for elaborating, yes i've tried that before inside the own prisma package I was creating to see if the custom path was working correctly, and was successfull

// inside the package prisma-geral/lib
const prisma = new (await import('./client')).PrismaClient()
console.log('created') // No error is thrown

The issue seems to appear when the client is called from out of the scope of the package:

const prisma = new (await import('@myorg/prisma-geral')).PrismaClient() // this points to: ./node_modules/@myorg/prisma-geral/lib/client
console.log('created') // error is thrown before reaching here

Thanks again for taking your time

[TheVoid-0]

Well, turns out that I was only being stupid, sorry for wasting your time, prisma works as intended so far.

In my package I was only publishing the "js" part of the generated client, the policy I've set to package.json.files was letting the query engines out, so when importing the package it would obviously not work.

So if others try to do the same, don't be like me and assure you are publishing everything prisma needs, wich is, everything that is inside de output folder.

Unfortunately the error message stranded me pretty far and this was the last thing I checked. Completly my fault anyway.

Thanks for the help and sorry for the useless issue!

[janpio]

That is an interesting error case that we were also definitely not aware of yet.

What is confusing me, if I understood correctly you did include the .prisma file about which the error message complains, but only the engine files (so the executables) were not included. Is that correct? I think we still have a bug then.

[TheVoid-0]

Yes @janpio you are correct, the only files missing on the published library were the query engines .node ones, once I've included them all started working without any problems so far. It looks like if they are missing, prisma fall back to look for everything on the default location node_modules/.prisma Wich will not exist in this scenario. Not sure what prisma should do, but perhaps showing an error message that the query engines are missing would give a better hint that something in the building and/or packaging went wrong.

[roxworks]

Getting something similar on a monorepo multi zone nextjs project

Trying to use prisma in an internal package but each app is giving a prisma error - unable to find schema.prisma same as here

I'm using custom generated client location, and have tried without a files [] and with, haven't found any success

if I manually copy paste the schema.prisma into the next build, it seems to at least cause different errors, but all the same feels like there's still something I'm missing here?

Tried based on @TheVoid-0's comments to adjust a files[] to include the .node files etc but wasn't able to get any working config off of that

[amirmamaghani]

any updates here? I'm having the same issue in monorepo nextjs project with turbo.

[janpio]

If you have a monorepo, then you have the same or similar error message but a different problem @amirmamaghani. Please open a new issue and optimally include a reproduction project for your situation - then we can take a look. Thanks!