-
We extended our prisma client with our custom bignumber extension that converts Types of property `price` are incompatible. Type `BigNumber` is not assignable to type `string` |
Beta Was this translation helpful? Give feedback.
Answered by
hayes
Apr 25, 2024
Replies: 2 comments 3 replies
-
For now, migrated to const db = new PrismaClient().$extends(BigNumberExtension);
type ExtendedProduct = Prisma.Payload<
typeof db.product,
"findUnique"
>["scalars"];
export const ProductObject =
builder.objectRef <
ExtendedProduct >
"Product".implement({
fields: (t) => ({
id: t.expose("id", {
type: "ObjectID",
}),
name: t.exposeString("name"),
description: t.exposeString("description"),
price: t.field({
type: "BigNumber",
resolve: (product) => product.price,
}),
}),
});
builder.queryField("product", (t) =>
t.field({
type: ProductObject,
args: {
id: t.arg({
type: "ObjectID",
required: false,
}),
},
resolve: async (_parent, { id }) => {
// now there is no type mismatching error
return db.product.findUniqueOrThrow({
where: { id },
});
},
})
); |
Beta Was this translation helpful? Give feedback.
0 replies
-
Instead of relying on |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It should be possible to entirely infer the generated types from the prisma client instead. The first versions of the prisma plugin worked this way. It ended up causing type-checking performance problems, and generating the types was the easiest way to get types that would be efficient for type-checking, but I don't think there is something that would prevent creating a type like:
PrismaTypesFromClient<typeof prisma>
that could be used instead of the generated types.There are some relevant examples of extracting types from the client here: prisma/prisma#5315 (comment). I'd be open adding a utility type for this to the plugin, but I'm not sure I have time right now to prioritize it. If yo…