👋 - I wanted to highlight some issues we are running into as part of the upgrade from prisma@3.14.0 => prisma@3.15.2. The prisma client generation has started to produce a

package.json

file which seems to breaks various assumptions of package managers (e.g. https://github.com/prisma/prisma/issues/13893, https://github.com/yarnpkg/berry/issues/4572). The latter is an issue I just filed on yarn but it is worth highlighting how it relates to the prisma change. For us, we have a polyglot monorepo that utilizes yarn workspaces. We also have 3 databases, all of which we configure and access with Prisma. Accordingly, we generate multiple prisma clients in one monorepo (with more to come as we add additional services/apps). We utilize the client generation output configuration to plop the generated client into the

./dist

of appropriately named and located package e.g.

@{company-name}/users-service-orm

(effectively wrapping it in our own package and tracking it as part of our package dependency graph). As a rule, all of our package build artifacts (

./dist

dirs for TS packages in our monorepo) are gitignored in our top-level

.gitignore

as well as package-specific `.gitignore`s. We agree with y'all that build artifacts shouldn't end up in version control. The

package.json

that ends up in client package's

./dist

dir are getting picked up by yarn workspaces 😞 e.g. yarn workspace globbing doesn't respect gitignored files/dirs. That is very much a yarn problem but it does feel like the change to produce

package.json

files as part of client generation relies heavily on the assumption that you will put the generated SDK into node modules. I've read your docs on this matter and understand the reasoning but would also argue that it is not necessarily the most natural solution in all cases (e.g. a large polyglot monorepo). One idea/proposal - would you consider configuration for the client generation that would allow us to avoid creating a package.json, equivalent to saying that we will manage these build artifacts ourselves? Open to other ideas as well.

Hey Joe, It looks like my colleague has continued the conversation over in this GitHub Issue.