-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Passing an extended PrismaClient breaks PrismaTestingHelper type #10
Comments
Seems related? prisma/prisma#17948 |
I have changed the types a bit and published a new version that you can install using
In my simple example this works - however, I personally don't use client extensions, so could you please verify that this solution works for you? Afterwards I can publicly publish version 1.1.1 with this fix. |
Thanks for addressing so quickly! I have tested the above fix version, and types do work correctly now 🎉 That said, I encountered another issue when using the FAIL src/thing.integration.ts (330 MB heap size)
● thing › should format a JSONL stream
TypeError [ERR_INVALID_ARG_TYPE]: The "iterable" argument must be an instance of Iterable. Received an instance of Object
105 | });
106 |
> 107 | return Readable.from(
| ^
108 | db.thing.cursorStream(
109 | {
110 | where: {
at getStream (src/thing.ts:107:19)
at async Object.<anonymous> (src/thing.integration.ts:288:24) I mention this here, because the same code works fine on its own, or when testing and not using Would you possibly have more time to look more into this? Should I create a separate ticket? Any other info I could provide, I'm thinking it would be nice to add some simple test cases perhaps? |
I think this happens because the PrismaTestingHelper wraps the You can (temporarily) add return Readable.from(
await db.thing.cursorStream( // ... to confirm my suspicion. If this fixes the problem, then I can add a denylist to the configuration, so that PrismaTestingHelper won't wrap certain calls like this one (since adding However, it might be possible that |
Hmm, something changed with the I'm getting back a Readable instance that looks like this: iterable is: Readable {
_readableState: ReadableState {
state: 6193,
highWaterMark: 1,
buffer: BufferList { head: null, tail: null, length: 0 },
length: 0,
pipes: [],
flowing: null,
errored: null,
defaultEncoding: 'utf8',
awaitDrainWriters: null,
decoder: null,
encoding: null,
[Symbol(kPaused)]: null
},
_events: [Object: null prototype] {},
_eventsCount: 0,
_maxListeners: undefined,
_read: [Function (anonymous)],
_destroy: [Function (anonymous)],
[Symbol(kCapture)]: false
} But trying to access it through TypeError: Cannot read properties of undefined (reading 'findMany') 🤔 sorry I'm not very proficient at Typescript/Javascript so might be missing something obvious? I'm guessing that by trying to read from the readable, I'm accessing the underlying result of awaiting the Update: confirmed that the result of calling |
That's probably some weird interaction with the cursorstream package. Unfortunately, I currently don't have the time to debug this in detail (especially with Christmas coming up), and I also can't really give you a time frame when I can get to it. You could try version 0.6.0 as a workaround because it uses a slightly different architecture - but I fear that this won't work either. If you can provide me a full repository to test this case (i.e. a Repo that I can clone, run npm install, run Prisma push and then simply run npm test to observe the error), then I can try to look at it again in the debugger to find out if it's something that I can fix. |
I've just released v1.2.0 with the broader types which fixes the typing problems at least and generally allows extended PrismaClients. I've closed the issue for now - but feel free to reopen it or create a new one if the issue is still relevant and you have a full reproduction repo. |
Using a client with extensions (e.g the
prisma-cursorstream
extension, but also others) breaks the expected type parameters ofPrismaTestingHelper
.It seems to always be missing
$on, $use
properties, likely due to this limitationTo work around this I had to cast it to
unknown
and then toPrismaClient
before passing the extended client to the helper, and when getting it back from the proxy:Could we narrow the expected object interface somehow?
The text was updated successfully, but these errors were encountered: