generate output relative to node_modules/@prisma/client

[Brandejs]

Problem

In our NX-based repository. We have several libraries that can contain their own schema.prisma.

The best place to then generate the prisma client is node_modules/@prisma/client/{module_name}. Because this is fully supported and does not cause the desired problems.

If the path is outside node_modules like
./src/generated

then in the case of multiple schemas it will break with a runtime error message
Error: Could not find mapping for model ...

But to achieve the generation to node_modules you need to specify the path relatively

for example

generator client {
    provider = "prisma-client-js"
    output = "../../../../node_modules/@prisma/client/moduleA"
    // import from '@prisma/client/moduleA'
}
// or moduleB
generator client {
    provider = "prisma-client-js"
    output = "../../node_modules/@prisma/client/moduleB"
    // import from '@prisma/client/moduleB'
}

which doesn't seem very practical to me.

Another problem with this approach is that in subsequent builds and deployments via docker. You need to re-generate @prisma/client. We have written a script that copies all schema.prisma from the libraries the application depends on to the dist folder. We then use the script to have all the @prisma/client re-generated.

find prisma -name '*.prisma' -exec npx prisma generate --schema={} \;

which works relatively well. But the problem arises in the path where the @prisma/client is generated. It's not to the node_modules of the application, but is created relative to the application. so it may create multiple node_modules in the parent folders.

Suggested solution

Because prisma if it doesn't have output set automatically generates to node_modules/@prisma/client. I think it would be practical to add an alternative option instead of output, for example clientName, which keeps the path to node_modules/@prisma/client but adds the clientName to path node_modules/@prisma/client/{clientName}

generator client {
    provider   = "prisma-client-js"
    // output  = "../../../node_modules@prisma/client/moduleA"
    clientName =  "moduleA"
    // import from '@prisma/client/moduleA'
}

Additional context

"prisma": "^4.8.0",
"@prisma/client": "^4.8.0",
"nx": "15.4.2",
"@nrwl/workspace": "15.4.2",
"@nx-tools/nx-prisma": "^4.0.2",

[MichalKliment]

Yes, that would be useful :)

[williamviktorsson]

We have the same issue as well.

Related issues : #8326 #2443

This comment highlights an instance where a user encounters an error when trying to use a custom output:

#2443 (comment)

This comment highlights how you currently have to work around the above issues, which is what this issue is addressing:

#2443 (comment)

[KrisKnez]

For mono-repo

Have a package for your database e.g. "database-a" with the following:

package.json

{
  ...
  "type": "module",
  "dependencies": {
    "@prisma/client": "^4.11.0",
    "prisma": "^4.11.0"
  }
  ...
}

schema.prisma

...
generator client {
  ...
  output = "./client"
}
...

index.js

export * from "./client/index.js"

Note that the location of the client may be different depending if you put your schema.prisma file inside the root folder of the package or inside /prisma/

Now you can import your database client using the following

import { PrismaClient as PrismaClientA } from 'database-a'
const prismaA = new PrismaClient()

[whyhankee]

Today, I also stumbled upon this issue. We are using npm workspaces, and the entire repo has one node_modules in the project's root. So the 2nd prima module conflicted with the first one.
The only alternative (workaround) I found was to indeed use a variant of the solution above. I generate the client in the ./src directory, and git ignore that folder.
The solution from the OP would be way more convenient though.

[adamghowiba]

Would love to bring back a discussion on this. We're big advocates for NX which uses a single node_modules folder.

We also commonly have to work with multiple different databases in the same project. It would be huge to be able to generate Prisma clients by a specific name as mentioned above.

Since the postinstall hook only accounts for schema.prisma placing it into node_modules requires some custom scripts to handle this which can be annoying.