prisma: no such file or directory, open '/path/schema.prisma' since 3.1.1

Hey everyone, we have a fix that is ready. Could you please give it a try? https://www.npmjs.com/package/@prisma/client/v/3.11.0-integration-fix-empty-path.1

npm install @prisma/client@3.11.0-integration-fix-empty-path.1

Again reporting the issue still exists in v3.3.0. However, thanks to @ykrop I have a temporary fix.

I was looking at the diff between the prisma generated index.js using v3.0.2 compared to using v3.3.0 and I saw that in v3.3.0 the path match strings are no longer quoted. See below:

Version 3.0.2

// folder where the generated client is found
const dirname = findSync(process.cwd(), [
  '"dist"',
  '""',
], ['d'], ['d'], 1)[0] || __dirname

Version 3.3.0

const dirname = findSync(process.cwd(), [
    "dist",
    "",
], ['d'], ['d'], 1)[0] || __dirname

So noticing the lack of quotes in the path strings, I added them in manually and the code works. My guess it is something to do with the findSync code trying to match a directory of an empty string?

For further context, the output path in my generator looks like this

generator client {
  provider        = "prisma-client-js"
  binaryTargets   = ["native", "rhel-openssl-1.0.x"]
  previewFeatures = ["interactiveTransactions"]
  output          = "../dist/"
}

Hopefully this all helps.

@millsp I just tried your fix but it doesn’t seem to solve the issue that when I build my app into ./build/index.js in a workspace, Prisma then tries to find the schema file at ./build/schema.prisma instead of ./prisma/schema.prisma.

Is this a different issue than the one you fixed?

Facing same issue on 3.9.1

Hit this using NPM workspaces for a monorepo (with Next.js).

I couldn’t get @henry-young’s ./generated/output fix to work for me - but figured another way that’s working:

(Update) example project: https://github.com/andyjy/prisma-multiple-schemas-monorepo-demo

1. prisma folder nested within monorepo workspace package e.g. <monorepo root>/packages/mydbpackage/prisma/schema.prisma
2. generator output= directly into <root>/node_modules/ (similar to the default when output isn’t specified)
3. … and use the @ prefix to scope the generated client node_module package name
4. Finally, be sure to import the client using the @prefix-scoped module pathname

Edit: @-scoped prefix not required; example: https://github.com/andyjy/prisma-multiple-schemas-monorepo-demo/tree/less_nesting

Works for me importing into a separate monorepo Next.JS package:

prisma.schema:

generator = "../../../node_modules/@~internal/prisma-myschema/client"

then:

import { PrismaClient } from "@~internal/prisma-myschema/client

(No dependencies required in the calling module package.json - node will automatically look in the root node_modules)

This is now working for me with multiple prisma schemas, managed separately from within one package within my monorepo, and generated separately into different top-level node_modules folders.

Using the @-scope prefix seems to force the client to be treated as an external dependency to be loaded from node_modules and not anywhere else. The client is then found correctly from the toplevel node_modules, not transpiled by Next.JS (as encountered in #10171), and the import treated successfully as CommonJS rather than hitting an error when the generated client attempts to require(‘./runtime…’) which I encountered due to my monorepo being configured with type="module".

(Thanks for the shares above, directed me to figure this out after digging around in the zaniness of the findSync() / __dirname logic - which appears to be attempting more magic than some might consider healthy 😬 )

I’m using npm workspaces and seeing this issue with Next.js.

still broken on 3.2.0 & 3.2.1 npm: 7.19.1 node 16.5.0 OS: Windows

Hey @millsp, can confirm your version mentioned in above works for solving this issue. Thanks for taking care! cc @Jolg42 @janpio

@millsp I tried the fix but I continue to have issues when if the process.cwd() !== dirname. For example, let’s say I build my node.js application in ./build and make sure ./build/schema.prisma is there.

node ./build/index.js would fail whereas cd build && node index.js would work.

I tried using an absolute url inside build/package.json but that also didn’t work: { "prisma": { "schema": "/myproject/packages/cli/build/schema.prisma" } }

So the schema looks in process.cwd() and not __dirname? If so, how would one overwrite this behavior. Wouldn’t it make sense to for the PrismaClientOptions to include a path to the schema.prisma file?

Also, for anyone wondering my folder structure is as follows:

node_modules/
prisma/
├─ generated/
│  ├─ output/
│  │  ├─ ...generated files here...
├─ migrations/
├─ schema.prisma
.gitignore
package.json
tsconfig.json

I was unable to have my schema file (and my generated output) in the root of the package. Nesting everything under /prisma works well for me.

Also here is a snippet from my package.json just incase anyone was needing help with yarn workspaces.

{
  "name": "@db/client",
  "private": true,
  "main": "prisma/generated/output/index.js",
  "types": "prisma/generated/output/index.d.ts",
...
}

So I can access prisma using import { PrismaClient } from '@db/client'; from another package in the workspace.

Just reporting that this is still an issue in the latest release 3.2.0. 3.0.2 is the latest version that doesn’t have this issue.

Can you please help us out and create a minimal reproduction of your setup that shows the problem occurring? Please put it in a Github repository and post the link here. Thanks.

https://github.com/s97712/prisma-workspace

I can also confirm a similar error occurs when you import prisma from a yarn workspace package. It seems to attempt to look and error in the first directory of the importing package. Error: ENOENT: no such file or directory, open '/Users/henryyoung/projects/project-monorepo/packages/server/.adirectory/schema.prisma'

Same problem here. @henry-young helped me work around the issue.

findSync is very eager to find a match for the generated output and one needs to work around the current implementation in order to trick it to fall back to __dirname.

First of all, having a path with only one segment will make the second passed matcher to findSync be an empty string, which matches everthing. So my first fix was to move around my setup so that the output path had 2 segments, i.e.

generator client {
  provider = "prisma-client-js"
  output = "./generated/output"
}

Next thing i did was make sure that my path would not be accidentally matched by any filename in the yarn cache, since prisma will recurse through that(!). Picking an output path like ./prisma/some-output will match for the first segment and break. ./generated/something-containing-prisma will break as well, because the second segment has prisma in it.

I ended up choosing ./generated/output, which works for my case. It sure would be nice to pass the dirname in the config, next to the output 😁

I can reproduce with https://github.com/s97712/prisma-workspace and https://github.com/coolcalcacol/prisma-issue.

We don’t officially support Yarn 2/3 but still going to mark this as confirmed bug for now.

Everyone else has this working in 3.0.x but it only broke in 3.1.1 @s97712 @henry-young @coolcalcacol @danielmahon?

This is correct.

I am currently using 3.0.2 with no issues. Issue only happens after upgrade to 3.1.1.

@s97712 Are you also getting this in context of a Yarn Workspace Package?

Yup

@s97712 Are you also getting this in context of a Yarn Workspace Package?

I can confirm. Setting it to "./generated/output" from "../prisma-client" fixes it for me.

I had the same problem after upgrading too. In my case seems to be caused by this code from index.js produced by Prisma npx generate:

// folder where the generated client is found
const dirname = findSync(process.cwd(), [
  "generated\\admin",
  "admin",
], ['d'], ['d'], 1)[0] || __dirname

As I have Prisma on a external folder and casually my project is in a path containing the same name given to generated scheme folder dirname var chose wrong path.

Schema output: project/prisma/generated/admin
Project: project/sites/admin/api

To solve it I just changed the generated prisma folder name.

Schema output: project/prisma/generated/adminSchema

Can you please help us out and create a minimal reproduction of your setup that shows the problem occurring? Please put it in a Github repository and post the link here. Thanks.

https://github.com/coolcalcacol/prisma-issue

Is this a new problem with 3.1.1 @revmischa? If not, please open a new issue as this one is about a change between Prisma 3.0.x and 3.1.1.

I was testing upgrading from 2.x right now. I just tried 3.0.2 and got the same missing schema error.

Edit: created ticket https://github.com/prisma/prisma/issues/9520

Can you please help us out and create a minimal reproduction of your setup that shows the problem occurring? Please put it in a Github repository and post the link here. Thanks.

I cannot reproduce in the new project, I will try to find out the real reason

Is this a new problem with 3.1.1 @revmischa? If not, please open a new issue as this one is about a change between Prisma 3.0.x and 3.1.1.

@danielmahon Also Yarn workspaces?

Yup, but I’m also using the traditional node_modules workflow, not pnp. (For the time being)

I forgot to mention, I’m seeing this using yarn v1. I haven’t confirmed this with V2.

On Wed, 29 Sep 2021, 3:10 am Jan Piotrowski, @.***> wrote:

@s97712 https://github.com/s97712 Are you also getting this in context of a Yarn Workspace Package?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prisma/prisma/issues/9435#issuecomment-929417980, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF73EX5R6OH42WINUSUPZO3UEHZJPANCNFSM5EX2VDVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.