Why is Prisma’s generated-client-code not checked into version control? Whenever a developer working in the codebase runs

git pull

, they must then run

prisma generate

to update their local environment for any schema changes others may have made. I’m surprised this is the default expectation because it is a hassle. We could create a git-hook to automatically regenerate on every

pull

, but it would be simpler to check-in the generated-client-code and add a CI check that ensures the client-code is up-to-date.

@Danny Nemer 👋 It depends on your use case. Usually generated code is consistent across Prisma versions so it’s fine if you don’t check that into version control.

Hey, @Ryan! Pardon, I do not quite understand “across Prisma versions”. Am I right that any team using Prisma requires every developer to routinely run

prisma generate

because another team member can make changes to the DB model/schema almost daily? Otherwise, any local env’s TypeScript will throw errors for out-of-sync client code. If so, I’m curious to know the design decision for why the generated code is excluded from version control. Seems like it prevents routinely breaking dev environments with no downsides. Thank you!

I don’t think it matters if you check it into version control or not. Generated code would always be the same given the same schema on the same Prisma version so you would only need to run an extra

prisma generate

if you don’t have it in version control, otherwise there’s no diff.

It makes your diffs messier

It is explained here. There seems to be two reasons IMO. One is that the client binaries are large, so add some weight to the github repo. A second is that the binaries are platform dependant, so unless all devs and all deploy environments are on the same platform, you might get issue with not building the client for your specific environment. This part of the architecture is understandable, but problematic for me. Especially if you deploy your services in a docker container that needs to build the client internally as it is built. However, using a sidecar or a node api to power the client means that this unavoidable

Generated code would always be the same given the same schema on the same Prisma version so you would only need to run an extra 

prisma generate

 if you don’t have it in version control, otherwise there’s no diff.

@Ryan How would the client code be generated (for your local environment) without running

prisma generate

and without syncing the generated code via version control?

You need

prisma generate

You need 

prisma generate

@Ryan I thought so. Hence, as mentioned in the initial post, whenever a developer working in the codebase runs

git pull

, they must then run

prisma generate

to update their local environment for any schema changes others may have made. Right?

Hence, as mentioned in the initial post, whenever a developer working in the codebase runs 

git pull

, they must then run 

prisma generate

 to update their local environment for any schema changes others may have made

Yes.

But, from inspecting my local 

node_modules/.prisma/client/

, I see there is 

libquery_engine-darwin.dylib.node

, a 35.8 MB file! Any idea what that file is? (edited)

That is the Prisma binary that helps with querying and managing connections to the database. You can read more about that in our docs 🙂

@Danny Nemer As Ryan says this is a how the client is implemented. It will either use a standalone binary that runs as a sidecar (if you are familiar with that pattern) or a node API add-on. I think this depends on 1. the version of the client you use, 2. a configuration option you set. Either way, this requires the client building script to download the binary that is compiled for your platform. I am using Prisma in a monorepo and have many clients, so you can imagine saving multiple Prisma clients to the source control is not really an option, so yes, each environment must run

prisma generate

I guess this might be automated with some

postinstall

scripts, although I know

yarn

in particular does not encourage that pattern.

@Russell Ormes I agree. But, notably,

prisma generate

produces multiple files. One is the client-specific binary. Another is the client-generated DMMF JS, which is small in size. It makes sense to commit the latter to version control because otherwise whenever a developer changes the schema, breaks the environment for all other engineers until they re-generate. A

postinstall

would only work whenever a user re-runs `yarn install`; however, the user is exposed to their environment breaking (or, in TS, not compiling) whenever any schema code changes. Ideally, we could specify the output path for just the DMMF. Then, anyone on the team can change the schema without breaking the dev environments of the other engineers. This would be separate from the binary (which is separate from the schema), so this is consistent for all platforms and deployments. No different than storing a

schema.graphql

, also a generated file, in version control.