Support output attribute for the generator

[heddendorp]

Perceived Problem

The generator does not support the output property of other prisma generators

Ideas / Proposed Solution(s)

Read and respect the output property in the schema definition like

generator nexusPrisma {
   provider = "nexus-prisma"
   output   = "../lib/nexus"
}

[jasonkuhrt]

This might bring significant internal complexity, I'd like to see strong use-cases for it first.

[heddendorp]

My use-case is a monorepo setup where I would like to keep the prisma files together and not modify the node-modules.

If this is not supposed to work, I would suggest to change the console output that indicates the new location. Right now the config does make it at least into the prisma generate console info.

[jasonkuhrt]

If this is not supposed to work, I would suggest to change the console output that indicates the new location.

You're saying that if it cannot be controlled it should not be mentioned in the logging to the user?

My use-case is a monorepo setup where I would like to keep the prisma files together and not modify the node-modules.

So this sounds like a subjective organizing principal which is fine but it would be good to know how, without this feature, what happens in your setup? What breaks? What are the blockers?

[jasonkuhrt]

I think a really good way to motivate this would be to start with a PR that changes the docs in such a way as to motivate this, e.g. a recipe for "if you have X problem then set output to Y".

[dimaip]

I have exactly the same usecase as @heddendorp, I want to build everything related to Prisma and Nexus once, and share it among our microservices.

[jasonkuhrt]

@dimaip could you share more about what that looks like. How does the db for one microservice translate to another in a useful way?

[filippodossena-mozart]

@jasonkuhrt my use-case: an API that needs to access 2 different prisma schemas/clients. I don't see any solution other than having the possibility to generate the nexus-prisma files into 2 different locations. Am I wrong?

[jasonkuhrt]

@filippodossena-mozart so you have two PSL files in your project modelling two different databases?

[dimaip]

@jasonkuhrt all microservices share the same database/schema/Prisma client in our case.
Basically it's a bunch of independent logic deployed and packaged separately, on top of existing monolith app.

[jasonkuhrt]

@dimaip so there is one PSL file. Thus Prisma Client is being emitted into one place I assume?

[dimaip]

I don't know what's a PSL file. I have one prisma schema file, one emitted Prisma client, that's used from a bunch of different places. I've now ditch nexus-prisma and use Pal.js to connect it to Nexus, so Prisma schema is decoupled from Nexus or nexus-prisma generator, so I can share it with services that don't need Nexus at all.

[filippodossena-mozart]

@jasonkuhrt yes, 2 different prisma schema files.

[jasonkuhrt]

@filippodossena-mozart interesting use-case, I think that seals it for me, in that case its essential.

[filippodossena-mozart]

@jasonkuhrt as a workaround I leveraged the nohoist option of yarn.
The following is the setup that seems to be working.

In the monorepo I created 2 packages, each one containing its own PSL file and an index.ts that exports from @prisma/client and nexus-prisma:

// index.ts
export * from "@prisma/client"
export * as NexusPrisma from "nexus-prisma" // `as` is required because prisma and nexus-prisma have some exports with equal names

The trick is to use the nohoist config in the root package.json of the monorepo:

"workspaces": {
    "packages": [
      "packages/*"
    ],
    "nohoist": [
      "**/@prisma/client",
      "**/prisma",
      "**/nexus-prisma"
    ]
  },

In this way, prisma and nexus-prisma are not hoisted and they are kept separated in each of the packages created above.

In the other packages that need to access the prisma client or the code generated by nexus-prisma, I do not import them directly from @prisma/client or nexus-prisma, but I import them from the packages created above.

[rostislav-simonik-nexus-prisma-admin]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on:

• npm package (@next-major dist-tag)
• GitHub release

Your semantic-release bot 📦🚀