Generated prisma types are missing relationships in their exported type.

[dannysmc95]

Bug description

So I am really not sure if this is a bug, my mistake or some really stupid feature.
I started using prisma in force a few days ago and so far, I love it, but I am struggling to understand how to use the generated types from @prisma/client for example:

I have a model called Faction, this faction creates a one to many relationship with users (noted as owner), so each faction is owned by a single user, but a user can own many factions.

Oddly, if I export Faction from the generated type by the @prisma/client it seems to be that if I was to do:
faction.owner will return as it does not exist, but in the model, it does exist, and if I was to do include: { owner: true } it's fine, but how do I type this for TypeScript so I can pass data to and from different places/functions/methods, etc.

For example I am working on a helper where I am running the same function (gets the faction through a different relationship) but I can't actually type it, because if I set the return as Faction it comes back with no owner attached therefore I just get owner does not exist.

How to reproduce

1. Use the model below, I cut out a lot of other stuff that isn't necessary, as this model is a lot bigger.
2. Generate the client, set a type as the Faction type exported from @prisma/client.
3. Observe how owner is absent from that type.

Expected behavior

I would expect, that there is some functionality that allows me to use the types generated by prisma that will contain the owner as well as the faction and should have some kind of logic to allow this?

Prisma information

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["mongoDb"]
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}

enum FactionChannelType {
  TEXT
  VOICE
  NEWS
  STAGE
}

// Core Models
model User {
  id            String           @id @default(dbgenerated()) @map("_id") @db.ObjectId
  discordId     String           @unique
  username      String
  discriminator String
  ownedFactions Faction[]        @relation(name: "OwnedFactions")
}

model Faction {
  id          String           @id @default(dbgenerated()) @map("_id") @db.ObjectId
  name        String
  roleId      String
  categoryId  String
  owner       User             @relation(name: "OwnedFactions", fields: [ownerId], references: [id])
  ownerId     String
}

Environment & setup

• OS: Ubuntu 20.04 focal
• Database: MongoDB
• Node: 16.13.0
• IDE: VSCode (Remote - SSH)

Prisma Version

prisma                  : 3.7.0
@prisma/client          : 3.7.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : 8746e055198f517658c08a0c426c7eec87f5a85f
Studio                  : 0.445.0
Preview Features        : mongoDb

[austincrim]

Hey @dannysmc95 👋 !

Since Prisma queries do not include relations by default (you have to use the include option), the generated types do not include them either. You can create the type you are looking for using one of our built-in utility types, though.

import { Prisma } from '@prisma/client'
type FactionWithOwner = Prisma.FactionGetPayload<{
  include: { owner: true }
}>

Here we use the FactionGetPayload type and pass in some query options as the generic parameter to get the desired type.

Let me know if you have any questions about this!

[adityapadekar]

@thw0rted
To understand what I want let's take one example

Case 1: Fetch Referral Code documents with user's name and email.
For this case I need only these two field.

Case 2: Fetch Referral Code documents with all the user's data

Case 3: Fetch Referral Code document with user's name, email, credit and status fields.

Now to do this I need to create a new type for each scenario and some of the fields are not optional in the user document

I attempted to use Partial<> to achieve this but encountered issues. Here's what I tried:

const adminPersonalData = Prisma.validator<Prisma.ReferralCodeDefaultArgs>()({
  include: { user: true } },
});

export type ReferralCodeWithAdminPersonalData = Prisma.ReferralCodeGetPayload<Partial<typeof adminPersonalData>>;

This results in the following type for ReferralCodeWithAdminPersonalData

type exp = {
    id: string;
    code: string;
    status: $Enums.ReferralCodeStatus;
    createdBy: string;
    createdAt: Date;
}

However, this approach didn't work as expected. I understand I could create separate types for each scenario, but that would result in redundant code. Also, fetching the whole object isn't efficient.

Is there a better way to achieve this? Am I missing something in my approach? Any suggestions or guidance would be greatly appreciated. Thank you!

[thw0rted]

I found it helpful to stop writing so many explicit types everywhere. If you let TS infer return types you can sometimes avoid having to write a lot of variations, without losing strong typing.

[adityapadekar]

@thw0rted I'm a bit confused as to what you mean by that.. can you provide a example?

[thw0rted]

It's more general advice. I used to write explicit return types on lookup methods:

type UserWithMinimalPosts = Prisma.UserGetPayload<{include: {post: select: typeof MINIMAL_POST_SELECT}}}>;
function getUser(...): UserWithMinimalPosts { ... }

I realized that the return type is redundant as long as it matches the output of my prisma.user.findUnique(...) call, and actively harmful if it isn't exactly the same. Variable typing (const user: UserWithMinimalPosts = getUser(...)) is the same.

Instead, I focus on typing function arguments. If a function only actually uses the username, email, and post contents, I can write the argument type as

type UserWithMinimalPosts = Prisma.UserGetPayload<{include: {post: {select: typeof MINIMAL_POST_SELECT}}}>;
function renderList(user: Pick<UserWithMinimalPosts, 'username' | 'email' | 'post'>) { ... }

This way, I can pass the response from a Prisma lookup that only returns a few user fields, or one that returns their full profile, as long as it includes at least the basic fields from the related Post model, but the typechecker will complain if I try to pass a response from a query with no include: { post: ... } at all.

If this isn't helpful, maybe you could have an example of how your types are being used?

[adityapadekar]

@thw0rted okay!... I'll look init, I'm new to prisma and also typescript to some extent, so I don't necessarily get everything you said but I'll run few experiment to understand this.

Thanks for everything.

[magrinj]

If you do a fallback call of your prisma client functions, you can just type it correctly like below and you should have the same behaviour as if you directly call the prisma client:

 async findMany<T>(args: Prisma.SelectSubset<T, Prisma.FactionFindManyArgs>) {
    return this.prismaClient.faction.findMany<T>(args);
  }

[jumantet]

Great, that works for me ! Many thanks !

[JefferyHus]

As of 4.16.2 this doesn't work :/

[ErnestoSalazar]

Agree with @JefferyHus, I had to make some adjustments to make it work in a newer version.

async findMany<T extends Prisma.FactionFindManyArgs>(args: Prisma.SelectSubset<T, Prisma.FactionFindManyArgs>) {
    return this.prismaClient.faction.findMany<T>(args);
  }

Here's another example with types in a separate file:

types.ts

export type UpdateUserParams<T> = Prisma.SelectSubset<T, Prisma.UserUpdateArgs>;

updateUser.ts

export const updateUser = async <T extends Prisma.UserUpdateArgs>(
  args: UpdatePlayerDbParams<T>,
) => {
  return prisma.user.update<T>(args);
}

This is the only solution that has worked for me so far, the function should still maintain the same behavior as if you call Prisma client directly just as magrinj mentions. And this will prevent creating and maintaining custom types.

I hope someone finds this useful.

[George3d6]

Is there really no better option to get proper typing here? This seems like a very-very common usecase and it adds tremendous complexity.

[Honatas]

I agree. It doesn't make sense to have to create my own types just to get my code that uses these relationships to transpile. The typecasts also look really ugly.

[gregg-cbs]

There 100% should be a way to generate types with relationships. Stringing this together manually and then having to keep the models and manually created relation types in sync is becoming a nightmare. Never mind when you sometimes import types from prisma folder and sometimes import them from your create types folder it becomes confusing - especially when intellisense recommends prismas non relation types first.

[conterio]

it shouldn't be this hard, let me just dev

[thw0rted]

It isn't "hard"; did you read the accepted answer? I had to spend some time with it to get a handle on how to use them, but the Prisma.{model}GetPayload types are exactly what everybody here seems to be asking for. I think the docs do a pretty good job of explaining how to use them now.

[swalker326]

Agreed I don't understand the outrage here. You can generate the type however you want. Prisma would have to generate every combination of relation and give it some default name. This gives the dev full control of the naming and included relations.

[KeentGG]

We should atleast add GetPayload to the Utility Types documentation, there's literally only one documented which is validator.

GetPayload is an essential tool for strict type-safety projects, especially i'll be using this with NestJS.

[Sliffcak]

+1 I think this should be a feature request or at least add to the documentation how to handle this use case for Typescript. Industry is moving towards Typescript, having this out of the box would be nice.

[thw0rted]

A similar discussion included a link to this docs page about advanced type usage, and I thought it might be helpful here as well.

[kilroyjones]

How do I even get validator to work? I keep getting that it's not defined on PrismaClient.

[ngharry]

Thanks heaps, it works like a charm for me

[bursteways]

Nice one, thanks. @thw0rted

[thetminko]

This is one of the pain that I am having also. When there are different variations, the codebase gets bloated with so many custom types. It would be great if generator can provide a type with optional relationships, so the developer can decide to use that or create custom types if want to be specific.

[gregg-cbs]

You can use Zod Prisma Types plugin for this. It generates zod schemas which you can ignore but it also generates types with relations .

[thetminko]

thanks for the suggestion!

[JefferyHus]

Frustrating, I tried every solution posted here and it just doesn't work. It is just one more reason to really just drop Prisma and go back to using a better ORM :)

[JefferyHus]

The only way I was able to go around this is by doing this

Prisma.UserGetPayload<{
    include: Prisma.UserInclude<any>;
}>

I tried so many thing instead of any but nothing worked as expected

[nla-asia]

export type Article = Prisma.ArticleGetPayload<{ include: { author: true }, }>;
I can include the relationship like this include all the fields from 'author' . Is there any way to define which fields from the relationship to include ?

[david1542]

I also need this type of functionality. This seems very basic and needed. Isn't there a way to add a flag to prisma generate that will also generate the relations themselves?

[danthedaniel]

This is what I do:

import { Prisma } from "@prisma/client";
import { Types } from "@prisma/client/runtime/library";

type PayloadToModel<T> = Types.Result.DefaultSelection<T>;
export type WithRelation<
    T extends keyof Prisma.TypeMap["model"],
    R extends keyof Prisma.TypeMap["model"][T]["payload"]["objects"]
> =
    PayloadToModel<Prisma.TypeMap["model"][T]["payload"]> &
    {
      [K in R]: PayloadToModel<Prisma.TypeMap["model"][T]["payload"]["objects"][K]>
    };

And then reference it as:

import type { WithRelation } from "@helpers";

function foo(model: WithRelation<"User", "comments" | "posts">) { ... }

I wrote out a bunch of types to make it so that it takes in User instead of "User" as a string, but it was way more complicated and in the end, unnecessary.

[AbdelrahmanSadat]

Came here through Google looking after facing the same issue. The first answer worked, but I imagine there can be a better-scaling solution, as I imagine this can get tedious quickly in larger projects.

[travelerr]

I’m using the marked answer for now but I agree, this is a super common use case and a better solution would be very useful. +1

[swalker326]

Since this is the first google search result, I'll add my comment here.

from the prisma docs

const videoWithVotes = Prisma.validator<Prisma.VideoDefaultArgs>()({
  include: { votes: true }
});
type VideosWithVotes = Prisma.VideoGetPayload<typeof videoWithVotes>;

[ZeldOcarina]

Yes this should be highlighted as the native way to go imo

[ericfel93]

i would expect prisma to generate VideoWithRelations type where all relationships are optional alongside with Video type

or maybe even have it on Video and not in another class, and not only the scalars

[swalker326]

I think making the type optional has interesting consequences with trying to access keys. Now typescript will want them checked for exsitence before getting any data out of them. Also the relations could have relations, would these also be optional attributes?

Could see a chain of

const relation = root.relation?.relations_relation?.relations_relations_relation
if (!relation) {
//handle this
}

[ericfel93]

yep, looking good IMO

[thw0rted]

In case you haven't looked at the accepted answer yet, what you're suggesting probably isn't needed. The issue is that if you query an object without an include for the relationship, you won't get the related record. You don't need the relationship to be optional in that case, you absolute are not going to have it. You just have to trust the return types for the query methods.

As an aside, I just started writing new Prisma-using TS code after a long time maintaining an old vanilla-JS codebase, where there was very little type information (/** @type ... */ etc). It took me a while to figure out why I had so much trouble with related records. The root issue was that we were explicitly typing a bunch of stuff using the shorthand / default Model types, like import { User } from '@prisma/client'. It's too easy to assume that the type with the simplest name is probably the one you want to use everywhere. As soon as I started stripping away explicit User return types and just letting TS carry the correct (very complex) return types around, everything was so much simpler. That, combined with learning to use e.g. UserGetPayload, made a huge difference.

[ericfel93]

my issue with the accepted solution is that I'm going to have many models
in the above example you gonna need to have one root object that all of the inner includes are optional, than you going to have relation that as its all includes and on and on
and regards the fact that even if you didn't included anything in the query you are going to have an optional relationship, IMO it is good. working with SqlAlchemy I got optional and it worked amazing

[nawangwe]

Found this library which might be of some help for now: https://github.com/Kalissaac/prisma-typegen

[wanjas]

This library or optional relations in general looks to me as an anti-patter. Relations in Prisma are fundamentally dynamic.

So using Prisma's built-in tools or using getters is a better practice.

Prisma's way

const userEntityInclude = {
  include: {
    posts: true,
    profile: true,
    etc: true,
  },
} satisfies Prisma.UserDefaultArgs;

export type UserEntity = Prisma.UserGetPayload<
  typeof userEntityInclude
>;

Getter's return type

import type { AsyncReturnType } from 'type-fest';

async function getUserEntity(id: string) {
  return prisma.user.findUnique({
    where: { id },
    include: {
      posts: true,
      profile: true,
      etc: true,
    },
  });
}

type UserEntity = AsyncReturnType<typeof getUserEntity>;

P.S. Both these ways provide you type-safety for even very complex includes/selects like the following example

async function getUserEntity(id: string) {
  return prisma.user.findUnique({
    where: { id },
    include: {
      posts: {
        include: {
          tags: true,
          categories: {
            select: {
              id: true,
              include: {
                translations: true,
              },
            },
          },
        },
      },
      profile: {
        select: {
          name: true,
          avatar: true,
        },
      },
      etc: true,
    },
  });
}

[nawangwe]

Thank you for that insight, I understand your point completely. I guess I would still consider that library if the number one item in my project rubric was rapid prototyping and not having to worry about updating my type declaration on my getter. But your method is what I'm gonna go with.

[thw0rted]

You don't need the 3rd party utility library, it's baked into Prisma:

import { Prisma } from '@prisma/client'

type UsersWithPosts = Prisma.PromiseReturnType<typeof getUsersWithPosts>

[mmaazahmed-diya]

why aren't they included in by default? my work around, invocles a deepy nested type decleration. surely there must be a better way?
type test= Prisma.orderGetPayload<{include:{order_items:{include:{partnerLocation:{include:{city:true}}}}}}>