Why do i get the wrong type
then i get this for
likes
field below, instead of | undefined
or something. am i doing it wrong?
4 Replies
You selected the bot's instantaneous insights. Let me compile your answer right away!
what i'm trying to do is when user is authenticated check the user id if user exist on the table of
likes
, and if not authenticated then return undefined field
This is a known limitation in Prisma's type inference for conditional or dynamic include/select arguments. When you use a union like likes: { select: ... } | false in your include/select, Prisma's generated types do not reflect the possibility that likes might be omitted or undefined—they always assume the "included" shape, not | undefined or | null.
This issue is discussed in several places:
- When you use a conditional include/select (e.g., likes: boolean or likes: { select: ... } | false), the generated type does not make the field optional or nullable, even though at runtime it may be missing. This is acknowledged as a bug/limitation in Prisma's type system and is tracked in issues like #13850, #20871, and #24829.
- The expected behavior would be for likes to be typed as likes?: ... or likes: ... | undefined, but currently, Prisma always infers the "included" type, regardless of the conditional logic in your query arguments.
Workarounds:
- You can use generics to make your helper functions' return types dynamic based on the include/select argument, but this does not fully solve the problem for unions or booleans—Prisma's types still do not mark the field as optional or undefined in these cases #20816.
- You may need to manually type the result or use type assertions as a workaround until Prisma improves this inference.
Summary:
You are not doing anything wrong—this is a limitation of Prisma's current type inference for conditional includes/selects. The field will not be typed as optional or undefined, even though it can be at runtime. This is a known issue and is being tracked by the Prisma team #13850, #20871, [#24829](https://github.com/prisma/p risma/issues/24829). 🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
You are not doing anything wrong—this is a limitation of Prisma's current type inference for conditional includes/selects. The field will not be typed as optional or undefined, even though it can be at runtime. This is a known issue and is being tracked by the Prisma team #13850, #20871, [#24829](https://github.com/prisma/p risma/issues/24829). 🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
Hey!
Can you please elaborate on what you are trying to achieve?
What type are you expecting which you aren't getting correctly