https://www.prisma.io/ logo
Join Slack
Powered by
Does the Prisma team have a relationship with the ...
# orm-help
h
Does the Prisma team have a relationship with the typescript team? I've got an issue that is probably more of a typescript performance issue than an actual Prisma issue. Trying to figure out if I should just open an issue in the TS repo, or if it would have more weight coming from someone working on Prisma.
Basically I've noticed that if you have a prisma client as an argument of a generic function that uses inference, TS has to generate a LOT of types and vscode becomes very laggy.
Copy code
import { PrismaClient } from "@prisma/client";
 
 function createField<Type extends string>(options: {
   type: Type;
   resolve: (db: PrismaClient) => unknown;
 }) {}
 
 createField({
   type: "Boolean",
   resolve: async (db) => {
     await db.user.findUnique({ where: { id: "1" } });
   },
 });
With a relatively small schema, this produces like 40k types in the compiler. Removing the generic reduces that to almost nothing
r
@janpio Might have a better idea here.
j
cc @millsp on the technical details with the types
Generally we have a good relationship with them, and also contribute ourselves from time to time, but nothing what I would call a "direct line" that can put more priority on things.
h
I created a simple repro here: https://github.com/hayes/prisma-ts-perf-issue and I’ll probably just open on issue on the typescript repo
m
I'm a bit surprised that you get such results. I set up a project in "real" conditions locally. Here's what I get:
Maybe it's a side effect of importing the 
d.ts
directly and the type count is incorrect. We do generate a lot of types for prisma.
h
I do have skipLibCheck enabled, I know there are a ton of generated types, but we shouldn't actually need a deep assignability check to infer db in the example.
I initially had it set up with the real Prisma client with the same results, just wanted to trim down the example a bit
Open in Slack
PreviousNext
Powered by