Support output attribute for the generator about nexus-prisma HOT 15 CLOSED

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.

from nexus-prisma.

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.

from nexus-prisma.

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

from nexus-prisma.

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?

from nexus-prisma.

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".

from nexus-prisma.

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.

from nexus-prisma.

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

from nexus-prisma.

@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?

from nexus-prisma.

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

from nexus-prisma.

@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.

from nexus-prisma.

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

from nexus-prisma.

@jasonkuhrt yes, 2 different prisma schema files.

from nexus-prisma.

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

from nexus-prisma.

@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.

from nexus-prisma.

🎉 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 📦🚀

from nexus-prisma.