[Bug] Prisma 6.6.0 - using "prisma-client" provider defaults to '@prisma/client'

[zngly-vlad]

Brief Outline

Using the new prisma-client breaks zenstack plugins typescript inference which rely on the prisma client import path

Description and expected behavior

Prisma 6.6.0 introduces a new client provider prisma-client
Plugins (from my testing zod & trpc) which import prisma types are now defaulting to import type { Prisma } from '@prisma/client';

Using my example below

generator client {
  provider = "prisma-client"
  output = "../src/generated/prisma-client"
}

plugin zod {
  provider = '@core/zod'
  output = './src/generated/zod'
}

generates:

/******************************************************************************
* This file was generated by ZenStack CLI.
******************************************************************************/

/* eslint-disable */
// @ts-nocheck

import { z } from 'zod';
;
import type { Prisma } from '@prisma/client';

;

This breaks the usability of any generated code which relies on the prisma-client types

Expected output:

using provider = "prisma-client-js" outputs correctly:

/******************************************************************************
* This file was generated by ZenStack CLI.
******************************************************************************/

/* eslint-disable */
// @ts-nocheck

import { z } from 'zod';
;
import type { Prisma } from '../../prisma-client';

;

findings

Searching for how the plugin system works. I can see that plugin options receive an options variable which contains the prisma client path.
When looking at how this is computed I can see the code looking for a hard coded prisma-client-js
This might be what is causing the plugins to not receive a prisma client path

https://github.com/search?q=repo%3Azenstackhq%2Fzenstack+%27prisma-client&type=code

Environment

• ZenStack version: 2.14.0
• Prisma version: 6.6.0
• Database type: Postgresql

Additional context
Add any other context about the problem here.

[ymc9]

Hi @zngly-vlad , the "prisma-client" generator is still in early access and completely untested with ZenStack yet.

[zngly-vlad]

100%, just thought I'd let you know my findings so far.

[ymc9]

Thank you! Appreciate it!

[mhodgson]

I did some research here and just want to comment that unfortunately it isn't as simple as updating the code to accommodate the new prisma-client generator name.

The Zenstack code uses ts-morph to modify the large index.d.ts file generated by the prisma-client-js generator. With the new prisma-client generator Prisma generates many smaller .ts files, not just type files. So at a minimum the part of the codebase that modifies the Prisma types needs to be re-factored to accomplish what is needed (appears to mostly be handling delegates) by modifying the appropriate .ts files in the new client structure.

Having said that, I think it is very desirable to have the combination of prisma-client + Zenstack with the --no-compile option. The result is all typescript code that can be generated into a codebase (not node_modules) without causing all sorts of ESM/CJS compatibility issues. It should also be easier on the TS language server since the files are broken up in the Prisma client.

[mhodgson]

@ymc9 it would be helpful for planning purposes to know if there is a chance the Zenstack team plans to support this feature or not. Like many teams we struggle mightily with a slow TS language server as our schema grows. Having the option to use the new prisma-client generator might ultimately outweigh the benefits of Zenstack.

I'd be happy to contribute to this effort if the team is committed to providing supporting for the new generator.

[ymc9]

Hi @mhodgson , I appreciate your time researching the issue and sharing the findings. We'll evaluate it and will share thoughts back here soon!

[ymc9]

I checked the "prisma-client" generation structure; some refactoring is needed to support it, but I think it's doable. However, I'm inclined to start the work when Prisma moves this new generator out of early access to avoid potential rework due to breaking changes.

[mhodgson]

@ymc9 really appreciate you circling back, and 100% the right call to wait until if/when it hits "preview".

[iksemot]

FYI "prisma-client" has just been moved to "preview" https://github.com/prisma/prisma/releases/tag/6.9.0 never mind, as @mhodgson correctly pointed out, I mixed the features

[mhodgson]

@iksemot I see the move of "queryCompiler" to Preview but I don't see any mention of the 'prisma-client' generator. These are separate features. Very easy to get these mixed up. Took me a while to figure out these were different features.