prisma: Schema File Not Found in non monorepo with custom `output`

We have prioritized this issue and we are actively investigating the root causes.

Just let us define the path ourselves in new PrismaClient() or with an environment variable, please.

Insane how many open issues I came across in all the different libraries (Prisma, TurboRepo, Next.js, pnpm) while googling for this problem. I’m using all of them (it’s basically a create-t3-turbo app) and I’m still not sure what the root cause is:

• Is it pnpm? Oh, I need to add public-hoist-pattern[]=*prisma* to my .npmrc. Too bad: It’s already there - not helping … anymore?
• Is it the new appDir feature of Next 13? No, I’m not using that.
• Is it not having serverComponentsExternalPackages configured? Oh wait no, that’s something Next.js takes care of automatically now for Prisma, so it doesn’t help putting prisma and @prisma/client there
• Is it Prisma’s heuristic for finding the schema.prisma file or one of the other 22 open Prisma issues regarding missing schema files?

My current approach for our Docker deployment is a custom output directory in schema.prisma:

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

…and a symlink in my Dockerfile:

RUN ln -s /app/node_modules/.prisma/client/schema.prisma /app/apps/my-nextjs-app/.next/server/chunks/schema.prisma

CMD ["node", "apps/my-nextjs-app/server.js"]

😞

If you’re using nextjs, try adding prisma to the serverComponentsExternalPackages in your config:

// next.config.js
const nextConfig = {
  experimental: {
    appDir: true,
    serverComponentsExternalPackages: ['@prisma/client'],
  },
};

https://beta.nextjs.org/docs/api-reference/next.config.js#servercomponentsexternalpackages

@roxkstar74 this is absolute chaos and I respect you immensely

Prisma homies, let’s get this one fixed 🙏 happy to get y’all in touch w/ Turborepo folks during NextConf

why is this file needed after the client has been generated? makes no sense

Hi I am the guy that figured this out, here’s some more help for people in the future

Just coming here to share a workaround by one of our community members who recently ran into this issue and shared their workaround in the public Prisma Slack:

I just had to manually edit the generated index.js file Exact error message was: error - Error: ENOENT: no such file or directory, open '/Users/roxworks/projects/dashboard/apps/<myprojectname>/.next/server/pages/api/auth/schema.prisma' to fix I had to open the generated runtime/index.js file from this to this:

I wrote a script that I keep on my top level that does these edits for me using sed (on most unix boxes which should work wherever you’re deployed)

the strategy I used involved pulling out each DB to its own super simple package with just a client.ts

then run this command for each of those packages (i just copy paste this line like 5x and replaced the package for each db) (I think you might only need this npm run dev)

sed -i 's/this.datamodel = import_fs6.default.readFileSync(config2.datamodelPath, "utf-8");/const myPath = config2.generator.output.value + "\/schema.prisma";this.datamodel = import_fs6.default.readFileSync(myPath, "utf-8");/g' packages/YOUR_DB_PACKAGE_NAME/YOUR_GENERATE_OUTPUT_PATH/runtime/index.js;

for all of your apps you’ll also need to do this, but this gets even MORE confusing because you’ll need to edit the next.js bundle files

luckily though it’s a similar line, for each app you’ll want this

sed -i 's/this.datamodel = import_fs6.default.readFileSync(config2.datamodelPath, "utf-8");/const myPath = config2.generator.output.value + "\/schema.prisma";this.datamodel = import_fs6.default.readFileSync(myPath, "utf-8");/g' apps/YOUR_APP_NAME/.next/server/chunks/*.js

I take these two commands, and copy paste for each DB/app as many times as needed into my fixprisma.sh file

Then, finally, I added to my turbo.json file after my prisma generate step to run bash fixprisma.sh as just a straight terminal command. You’ll also want to run it after your build step so it picks up the new next.js compiled files

GO FORTH AND PROSPER MY FRIENDS

Just coming here to share a workaround by one of our community members who recently ran into this issue and shared their workaround in the public Prisma Slack:

I just had to manually edit the generated index.js file Exact error message was: error - Error: ENOENT: no such file or directory, open '/Users/roxworks/projects/dashboard/apps/<myprojectname>/.next/server/pages/api/auth/schema.prisma'

to fix I had to open the generated runtime/index.js file from this to this:

Symlinking seems to work but that is such a hack. PNPM does not work with the 4.8.x version but works with 3.x.x. Without looking too deep into Prisma internals why do we need a schema file after the client is generated and at runtime?

I’m really looking forward to having a better solution, but for now we’re copying the schema to a bunch of different places (thanks @kristinlindquist ^):

const copyThePrismaSchemaHere = [
  "./server/pages/foo",
  "./server/pages/bar",
  "./server/pages",
  "./server/chunks",
];

/** @type {import('next').NextConfig} */
const nextConfig = {
  /* ... */
  webpack: (config) => {
    config.plugins.push(
      new CopyWebpackPlugin({
        patterns: copyThePrismaSchemaHere.map((loc) => ({
          from: "../prisma-client.gen/schema.prisma",
          to: loc,
        })),
      })
    );
    return config;
  },
};

Each time I use Prisma from a new location I get a new error. I roll my eyes, add the path to the list, check this GitHub issue, and keep moving. 🤭

In case it helps anyone, I used the copy plugin to copy around schema.prisma:

const CopyPlugin = require('copy-webpack-plugin');

const copyPrismaSchema = (file) => ({
  from: '../../packages/datalab-prisma/lib/prisma/schema.prisma',
  to: path.join(__dirname, file),
});

const moduleExports = {
  webpack: (_config, options) => {
      config.plugins.push(
        new CopyPlugin({
          patterns: [
            copyPrismaSchema('.next/cache/webpack/client-development/'),
            copyPrismaSchema('.next/cache/webpack/server-development/'),
          ],
        })
      );
      return config;
   },
  ...
}

So it’s not an exact replica of what we have. I cut corner to make this quick. Things are more complicated in our repo than it is here. Tbh the error I see in the reproduction repo is similar but not the same as our working repo, remove the @nestjs/schematics part and the call stack that is different. Close enough to think it should suffice.

Difference between our setup and this one below :

• We didn’t use create-t3 stack. We setup our stack by hand using nx and by reading the docs on how to setup each tools. Very similar to t3-stack so I use that here to save time. If you’re looking to create the exact same setup. Run npx nx generate @nrwl/next:application web2 setup next-auth, prisma, tRPC and call @myorg/prisma-db instead of @prisma/client, should be similar to what we have.

You can also create a NestJS app if you like to try it out too, both share the same schemas, just not the logic.

https://github.com/maxime4000/prisma-schema-nx

Using pnpm, it’s a huge pain because no solution above worked for me 😕

Any progress on this?

Sorry, if my comment sounded a bit rude! After spending hours looking for a solution I was seriously thinking about just abandoning pnpm and TurboRepo and going back to good old npm + Next.js + Prisma, which in my experience works just fine. Good to know that you guys are looking into this.

Thanks @njmaeff for your excellent reproduction (and not deleting it after all this time) - I could confirm the problem with that easily. As @MatsG23 had written, removing the custom output path in your schema.prisma resolves the error in your reproduction as a workaround.

Everyone else, if your project is using Next.js but a monorepo, or no custom output setting, then this issue is technically not the correct one for you. We have collected similar issues under the topic: ENOENT schema.prisma label, and also added the topic: monorepo label to many of them: https://github.com/prisma/prisma/issues?q=is%3Aopen+label%3A"topic%3A+ENOENT+schema.prisma"+sort%3Aupdated-desc Please subscribe to or comment a reproduction to one of these to be updated about updates. We are currently working on a workaround and close to share that for feedback 🔜

If your project is not using Next.js (@serg06?), please definitely open a new issue - optimally with a reproduction we can try ourselves. Thanks.

Thanks for this solution, @roxworks! I’ve had success with this locally, but upon deploying to Vercel, I’m met with the issue again. Is this something you’ve had success with on Vercel?

Nope! I gave up on vercel and went to a digitalocean droplet

My workaround is to copy the schema.prisma file from it’s location and paste it into /.../.next/cache/webpack/client-development/<paste_here>. It’ll persist across dev runs, and then if the cache ever is reset I do it again. Not exactly the ideal workaround but simpler than modifying the runtime/index.js file which is rebuilt every time.

I’m not entirely sure if this is a Next.js issue or a Prisma issue.

Optimally open a new issue with a description of your specific cas @SomeoneWeird, if it is not identical to the one described above. A reproduction repository is optimal, so we can just run this ourselves and see (and later also test our potential fixes).

Rgr, opened https://github.com/prisma/prisma/issues/12588

I am also running into this now. I am using lerna to manage a monorepo, with prisma schema + client being instantiated in one package, and being required into another package which is a NextJS project.

@pantharshit00

Try this repro. https://github.com/njmaeff/prisma-issue-10433

I have this issue too and it is related to this line of code and the findSync function. The .next directory is read first and if your relative output matches any subdirectories (like mine do with keywords like “server”, and “client”), then it selects the wrong dirname for the configuration.

https://github.com/prisma/prisma/blob/e679b61111a9dca7200c7e0626b08a3d8cc44c9b/packages/client/src/generation/utils/buildDirname.ts#L38-L41