P
Prisma•3mo ago
goYsticks

"prisma-client" CI Best Practices

I'm looking at migrating to the "prisma-client" instead of "prisma-client-js" but I'm curious what the thoughts on CI best practice for this are. Before I was grabbing the @prisma/client and putting it into an artifact for differnt steps to retreive. That was a 60MB file. The new generated client is 130MB.
4 Replies
Prisma AI Help
Prisma AI Help•3mo ago
Skipping coffee for instant knowledge! Let's brew that AI answer now. Here are CI/CD best practices for migrating to the new prisma-client: - Do not commit the generated client to VCS. The official guidance is to exclude the generated directory from version control, as it includes platform-specific engine files (until Prisma fully transitions to TS) (Generated Prisma Client Persistence, prisma-client (Preview) › Exclude from VCS). - Always generate the client during your CI build step in the repo that owns the schema, using an explicit output path (required for prisma-client, and mandatory in Prisma 7). Example: - schema.prisma: 
    generator client {
      provider = "prisma-client"
      output   = "../src/generated/prisma"
    }
    
    generator client {
      provider = "prisma-client"
      output   = "../src/generated/prisma"
    }
Then run prisma generate in CI and import from that path (Generating Prisma Client, prisma-client (Preview)). - If you cache dependencies/builds (Vercel, etc.), add prisma generate in postinstall or your CI build script to avoid stale clients: 
  "scripts": { "postinstall": "prisma generate" }
  
  "scripts": { "postinstall": "prisma generate" }
or call it in your custom build step (Deploy to Vercel › Build configuration). - For monorepos or shared packages: prefer generating per service/package in its own output directory; ensure migrations run in a controlled step (often as part of the owning service’s deploy) and keep changes backward compatible using expand/contract if multiple services consume the DB (Sharing client between microservices). - To reduce artifact size: - Consider enabling the Rust-free “queryCompiler” p review to eliminate engine binaries (no Rust query engine is downloaded/shipped), paired with driverAdapters. This substantially reduces build artifacts: 
    generator client {
      provider        = "prisma-client-js"
      previewFeatures = ["queryCompiler", "driverAdapters"]
    }
    
    generator client {
      provider        = "prisma-client-js"
      previewFeatures = ["queryCompiler", "driverAdapters"]
    }
Use the appropriate JS driver adapter (e.g., @prisma/adapter-pg) (Deployment overview, Troubleshooting binary size, Deploy Prisma ORM). Note: This is Preview; confirm it fits your environment. - Avoid packaging the generated client as a large CI artifact. Prefer regenerating in each job/step that needs it, using caching for npm/pnpm and prisma engines if applicable. With prisma-client, generation is deterministic to your schema and platform. If you need to ship an artifact, keep it platform-specific and ensure it’s regenerated when schema changes (e.g., tie cache key to schema.prisma hash and Prisma version) (Generating Prisma Client).
Nurul
Nurul•3mo ago
Was the bot answer helpful? The generated client should not be committed in your repository
goYsticks
goYsticksOP•3mo ago
Not really, its painfully slow to re-generate in each step of the CI. But I can continue storing it in an artifact.
Avi
Avi•3mo ago
is this really true now that rust-free is in GA? the docs say that we can start checking that into git since there's no architecture-specific binaries anymore
In the future, you can safely include the generated directory in version control when Prisma ORM is fully transitioned from Rust to TypeScript.
from here

Did you find this page helpful?