prisma: VScode behavior is very slow while using clientExtensions
Bug description
Today I updated prisma to 4.10.0 and immediately experienced very slow VScode behavior in project where prisma is installed.
EDIT:
After few hours of playing with VScode extensions, code, schema, … I ended up with new observings.
Seems like the version is not causing the issue. Let me explain:
Before updating to version 4.10.0 I prepared this code for extending the prisma client:
.$extends({
result: {
iOrder: {
orderNumber: {
needs: { id: true, randomNumber: true },
compute(order) {
return +`${order.id}${order.randomNumber}`;
}
}
}
},
model: {
iOrder: {
byOrderNumber: (vs: number) => {
const str = `${vs}`;
const split = [parseInt(str.slice(0, str.length-2)), parseInt(str.slice(str.length-2))];
return {
id: split[0],
randomNumber: split[1]
};
}
} satisfies Record<string, (...args: any) => Prisma.IOrderWhereInput>,
}
});
Right after updating the version I extended the client with this code and added clientExtensions to previewFeatures and ran npx prisma generate. After that the VScode window was very slow (intellisense, error higlighting, …).
For example after typing (new PrismaClient()). the intellisense would show up in ± 13 seconds. Because of that I wrongly blamed the version - sorry about that.
Now what I discovered:
- I removed the extending code (see above) and the intellisense show time dropped to ± 3 seconds.
- I removed
clientExtensionsfrompreviewFeaturesand the show time was almost instant (as it was).
So it seems like that the clientExtensions preview feature is causing this problem.
Sorry about not posting our schema as we find it sensitive. But there are 24 models.
Btw this is my machine.
EDIT2:
This slow behavior is not immediate. It shows up after few minutes of working. And it seems, like prismaTransactionClient. takes longer to show intellisense than prismaClient.
How to reproduce
- use
clientExtensionspreview feature - extend the client
- experience the slowness of VScode - for example intellisense
Expected behavior
VScode should be quick with and without using clientExtensions.
Environment & setup
- OS: Windows 11
- Database: PostgreSQL
- Node.js version: 16.15.1
Prisma Version
prisma : 4.10.0
@prisma/client : 4.10.0
Current platform : windows
Query Engine (Node-API) : libquery-engine ca7fcef713137fa11029d519a9780db130cca91d (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine : migration-engine-cli ca7fcef713137fa11029d519a9780db130cca91d (at node_modules\@prisma\engines\migration-engine-windows.exe)
Format Wasm : @prisma/prisma-fmt-wasm 4.10.0-84.ca7fcef713137fa11029d519a9780db130cca91d
Default Engines Hash : ca7fcef713137fa11029d519a9780db130cca91d
Studio : 0.481.0
Preview Features : clientExtensions
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 7
- Comments: 17 (6 by maintainers)
I’m also seeing something similar with my schema on the latest Prisma 4.11.0 (also seeing the same behavior on all previous working versions, 4.9 and above). Have a few hundred tables and doing a performance trace with TypeScript and analyze-trace shows me there’s several hot spots related to evaluating types that are suffixed with “Needs”. Looked in the index.d.ts and saw those were all client extension related. Assuming I’m reading this trace correctly, seeing compilation times anywhere from 20-40 seconds just to evaluate those. For whatever it’s worth, I have several other preview features enabled too, not sure if any other ones would trigger this issue potentially.
VSCode and the typechecker basically grind to a halt and it’s difficult to work. Once I remove the client extension, everything is speedy again.
I was trying to use client extensions to implement callback-free interactive transactions as shown here.
Hey, we have refactored the code generation to switch from fully generated types to dynamic typing. This should have improved the performance drops that you have reported. I’d love to hear your feedback @niba @anton-g @aniravi24 @drekthral to know if things got better on your end. Thanks. The fix is available in
4.16.0.I have the same problem. My vscode started working very slowly and after a few days I discovered that the reason is prisma extension mechanism. I think typescript has some problems with parsing prisma extensions types. Maybe there is some recurrency in types or something like that?
I managed to get this error from tsc:
error TS2321: Excessive stack depth comparing types 'GetClient<PrismaClient<PrismaClientOptions, never, RejectOnNotFound | RejectPerOperation | undefined, { result: {} & Record<string, {}> & { ...; }; model: {} & Record<...>; client: {}; query: {}; }>, {}>' and 'TransactionClient'.what is weird I only got this error once and I’m unable to get it again (haven’t changed anything in code)Awesome @aniravi24, that is a great hint for us to double check.
It turns out my issue might have been caused by a problematic type cast in the Prisma example for callback-free interactive transactions here. This type cast causes the typechecker to become much slower, and when moving this
$beginfunction outside of the client extension into a separate function, it hangs the typechecker altogether (the TS perf trace file gets larger and larger with the typechecker never finishing, even after several minutes). Removing the type cast (as) and ignoring the type error was the solution I went with for now.Removing client extensions does make navigating VSCode smoother (and typechecking faster), but not as big of an improvement as changing this type cast. Just thought I’d comment here in case anyone else runs into this too.
Adding my experience with the same issue here: prettier on save would take 4-6s, intellisense was super slow. This isn’t the case when not calling
$extendson the prisma client.By digging a bit I saw that eslint was complaining that applying the rules was taking a long time.
With trial and error, commenting these two rules
solved the problem completelyhelped a bit.edit: it’s now still slow gradually and needs a restart every so often.