P
Prisma•7mo ago
roguehusky3

Provider `prisma-client` vs `prisma-client` js with preview features

I have a few questions about the client provider changes v6 -> v7 
generator client {
  provider = "prisma-client-js"
  output   = "../app/generated/prisma"
}
generator client {
  provider = "prisma-client-js"
  output   = "../app/generated/prisma"
}
- generates a client where a single libquery_engine-debian-openssl-3.0.x.so.node file is found and used. According to the docs:
The prisma-client-js is the default generator for Prisma ORM 6.X versions and before. It requires the @prisma/client npm package and generates Prisma Client into node_modules.
1. If so, then why does it respect the output setting instead of generating into node_modules? 
generator client {
  provider = "prisma-client-js"
  output   = "../app/generated/prisma"

  previewFeatures = ["queryCompiler"]
}
generator client {
  provider = "prisma-client-js"
  output   = "../app/generated/prisma"

  previewFeatures = ["queryCompiler"]
}
As of v6.7.0 , Prisma ORM has the queryCompiler Preview feature. When enabled, your Prisma Client will be generated without a Rust-based query engine binary: generator client { provider = "prisma-client-js" previewFeatures = ["queryCompiler", "driverAdapters"] } Note that the driver adapters Preview feature is required alongside queryCompiler.
Specifying just queryCompiler results in a (non-functional) client with only JS/TS files, but prisma generate gives no error. Adding "driverAdapters" results in query_compiler_bg.wasm file in the generator. But, no more target-dependent libssl.node file anymore. The docs mention at least the WASM file:
Components that cannot yet be moved are being re-packaged into a WASM file included in the @prisma/client npm module. This WASM file functions as the query compiler, simplifying workflows without significant API changes.
2. Why do we need two features and what happens without driverAdapters Rest of questions in the top comment 😄
2 Replies
Prisma AI Help
Prisma AI Help•7mo ago
You selected the carefully hand-crafted route. A dev artisan will respond soon. Meanwhile, the #ask-ai channel awaits if you're curious!
roguehusky3
roguehusky3OP•7mo ago
On to prisma-client (Early Access): 
generator client {
  provider = "prisma-client"
  output   = "../app/generated/prisma"
}
generator client {
  provider = "prisma-client"
  output   = "../app/generated/prisma"
}
Here are the main differences compared to prisma-client-js: Supports ESM and CommonJS via the moduleFormat field Outputs plain TypeScript that's bundled just like the rest of your application code
This second claim isn't quite true, unless you enable the previewFeatures, you will get a client that supports ESM but still has libquery_engine-debian-openssl-3.0.x.so.node file. 3. Why aren't the previewFeatures necessary here instead of making these changes part of changing from prisma-client-js to prisma-client? Let's enable the preview features: 
generator client {
  provider = "prisma-client"
  output   = "../app/generated/prisma"

  previewFeatures = ["driverAdapters", "queryCompiler"]
}
generator client {
  provider = "prisma-client"
  output   = "../app/generated/prisma"

  previewFeatures = ["driverAdapters", "queryCompiler"]
}
Now we end up with a ESM-compatible generated client with no binary components. 4. Why can we not yet include this generated client in source control?
In the future, you can safely include the generated directory in version control when Prisma ORM is fully transitioned from Rust to TypeScript.
There are only TS source files in the generated client now, is it still a bad idea to include this generated client in Git? 5. Lastly, the generated client still depends on (types from) the @prisma/client package. Will this be changed so the client can be generated without the @prisma/client package installed? And can we, for now, move @prisma/client into devDependencies since it is only used for types?

Did you find this page helpful?