Prisma vs typegraphql-prisma input mismatch

[JClackett]

Describe the Bug I have been getting these type errors on the latest typegraphql-prisma updates and can't figure out if its something to do with my setup or a library issue, so apologies in advance but I didn't know where else to ask this!

I'm using: typescript: v4.5.2 typegraphql-prisma: v0.18.2 prisma: v3.6.0

 @Query(() => Team, { nullable: true })
  async team(@Args() args: FindFirstTeamArgs): Promise<Team | null> {
    return await prisma.team.findFirst(args)  // <--- Error here
  }

Excessive stack depth comparing types '{ where?: TeamWhereInput | undefined; orderBy?: TeamOrderByWithRelationInput[] | undefined; cursor?: TeamWhereUniqueInput | undefined; take?: number | undefined; skip?: number | undefined; distinct?: ("id" | ... 23 more ... | "updatedAt")[] | undefined; }' and 'TeamFindFirstArgs'.

 Types of property 'AND' are incompatible.
          Type 'TeamWhereInput[] | undefined' is not assignable to type 'Enumerable<TeamWhereInput> | undefined'.
            Type 'TeamWhereInput[]' is not assignable to type 'Enumerable<TeamWhereInput> | undefined'.

The excessive stack depth I'm assuming is due to the recursive nature of the TeamWhereInput, but what's also weird is i don't have that error on another project using the exact same environment, so debugging is proving very difficult! Maybe you have some ideas? Also, my server is building on Heroku but not locally, so again seems like maybe a local setup issue?

Thanks!

[JClackett]

It seems like generated TeamWhereInput[] isn't the same as prisma's "Enumerable" version??

Enumerable<TeamWhereInput>

Enumerable<T> = T | Array<T>;

here's a fuller error log:

Argument of type 'FindFirstTeamArgs' is not assignable to parameter of type '{ select?: TeamSelect | null | undefined; include?: TeamInclude | null | undefined; rejectOnNotFound?: RejectOnNotFound | undefined; ... 5 more ...; distinct?: 

Enumerable<...> | undefined; }'.
  Types of property 'where' are incompatible.

    Type 'import("<path>/node_modules/@generated/resolvers/inputs/TeamWhereInput").TeamWhereInput | undefined' is not assignable to type 'import("/<path>//node_modules/.prisma/client/index").Prisma.TeamWhereInput | undefined'.

      Type 'import("<path>/node_modules/@generated/resolvers/inputs/TeamWhereInput").TeamWhereInput' is not assignable to type 'import("/<path>/node_modules/.prisma/client/index").Prisma.TeamWhereInput'.

        Types of property 'AND' are incompatible.
          Type 'TeamWhereInput[] | undefined' is not assignable to type 'Enumerable<TeamWhereInput> | undefined'.
            Type 'TeamWhereInput[]' is not assignable to type 'Enumerable<TeamWhereInput> | undefined'.ts(2345)

[MichalLytek]

@JClackett It's not because GraphQL does not support such input unions. However, TypeScript should not complain about that.

[JClackett]

Hmm any idea what is going on here then? I've tried reverting to many different TS versions but still getting this error every time I reload/reset the vscode TS version.

[MichalLytek]

[JClackett]

Yeah that also works for me, so must be linked to it being more deeply nested or something? Will continue to look into it

[JClackett]

So its either the nested nature of it, or something specific with my data schema. If I do the same thing as you did above but with the prisma input and the generated input I get the error:

import P, {Prisma} from "@prisma/client"
import * as Generated from "@generated"

// Prisma's Input
export type OrderWhereInput = {
  AND?: Prisma.Enumerable<OrderWhereInput>
  OR?: Prisma.Enumerable<OrderWhereInput>
  NOT?: Prisma.Enumerable<OrderWhereInput>
  id?: Prisma.StringFilter | string
  type?: Prisma.EnumOrderTypeFilter | P.OrderType
  number?: Prisma.IntFilter | number
  amount?: Prisma.IntNullableFilter | number | null
  bespokeAmount?: Prisma.IntNullableFilter | number | null
  totalAmount?: Prisma.IntFilter | number
  orderDate?: Prisma.DateTimeNullableFilter | Date | string | null
  status?: Prisma.EnumOrderStatusFilter | P.OrderStatus
  paymentStatus?: Prisma.EnumOrderPaymentStatusFilter | P.OrderPaymentStatus
  customSeats?: Prisma.IntNullableFilter | number | null
  customPriceAmount?: Prisma.IntNullableFilter | number | null
  planEndDate?: Prisma.DateTimeNullableFilter | Date | string | null
  paymentRequirement?: Prisma.EnumPaymentRequirementNullableFilter | P.PaymentRequirement | null
  price?: Prisma.XOR<Prisma.PriceRelationFilter, Prisma.PriceWhereInput> | null
  priceId?: Prisma.StringNullableFilter | string | null
  userId?: Prisma.StringFilter | string
  billingAccountId?: Prisma.StringFilter | string
  billingAccount?: Prisma.XOR<Prisma.BillingAccountRelationFilter, Prisma.BillingAccountWhereInput>
  user?: Prisma.XOR<Prisma.UserRelationFilter, Prisma.UserWhereInput>
  team?: Prisma.XOR<Prisma.TeamRelationFilter, Prisma.TeamWhereInput>
  teamId?: Prisma.StringFilter | string
  invoices?: Prisma.InvoiceListRelationFilter
  createdAt?: Prisma.DateTimeFilter | Date | string
  updatedAt?: Prisma.DateTimeFilter | Date | string
}

// typegraphql-prisma's input
export declare class GqlOrderWhereInput {
  AND?: GqlOrderWhereInput[] | undefined;
  OR?: GqlOrderWhereInput[] | undefined;
  NOT?: GqlOrderWhereInput[] | undefined;
  id?: Generated.StringFilter | undefined;
  type?: Generated.EnumOrderTypeFilter | undefined;
  number?: Generated.IntFilter | undefined;
  amount?: Generated.IntNullableFilter | undefined;
  bespokeAmount?: Generated.IntNullableFilter | undefined;
  totalAmount?: Generated.IntFilter | undefined;
  orderDate?: Generated.DateTimeNullableFilter | undefined;
  status?: Generated.EnumOrderStatusFilter | undefined;
  paymentStatus?: Generated.EnumOrderPaymentStatusFilter | undefined;
  customSeats?: Generated.IntNullableFilter | undefined;
  customPriceAmount?: Generated.IntNullableFilter | undefined;
  planEndDate?: Generated.DateTimeNullableFilter | undefined;
  paymentRequirement?: Generated.EnumPaymentRequirementNullableFilter | undefined;
  price?: Generated.PriceRelationFilter | undefined;
  priceId?: Generated.StringNullableFilter | undefined;
  userId?: Generated.StringFilter | undefined;
  billingAccountId?: Generated.StringFilter | undefined;
  billingAccount?: Generated.BillingAccountRelationFilter | undefined;
  user?: Generated.UserRelationFilter | undefined;
  team?: Generated.TeamRelationFilter | undefined;
  teamId?: Generated.StringFilter | undefined;
  invoices?: Generated.InvoiceListRelationFilter | undefined;
  createdAt?: Generated.DateTimeFilter | undefined;
  updatedAt?: Generated.DateTimeFilter | undefined;
}

declare function prisma(input: OrderWhereInput): unknown
declare const input: GqlOrderWhereInput

prisma(input)

Excessive stack depth comparing types 'GqlOrderWhereInput' and 'OrderWhereInput'.ts(2321)
Argument of type 'GqlOrderWhereInput' is not assignable to parameter of type 'OrderWhereInput'.
  Types of property 'AND' are incompatible.
    Type 'GqlOrderWhereInput[] | undefined' is not assignable to type 'Enumerable<OrderWhereInput> | undefined'.
      Type 'GqlOrderWhereInput[]' is not assignable to type 'Enumerable<OrderWhereInput> | undefined'.ts(2345)

[JClackett]

Looks like someone using nestjs is facing similar issues:

https://github.com/unlight/prisma-nestjs-graphql/issues/65

[Luke265]

This problem has been fixed in typescript version 4.5.3 and above. This issue can be closed.

https://github.com/microsoft/TypeScript/issues?q=milestone%3A%22TypeScript+4.5.3%22+

[JClackett]

I've been using 4.5.4 and it's definitely not fixed

[unlight]

It's not fixed even in 4.6.0-dev As a quick (dirty hack) fix you can try this patch solution - https://github.com/unlight/prisma-nestjs-graphql/issues/65#issuecomment-994742228

[MichalLytek]

@unlight It's a weird solution cause both types are recursive, so you can compare it until stack overflows 😛

[JClackett]

Yeah I have tried patching typescript, but didn't seem to make a difference, as @MichalLytek mentioned, not really sure how it would help with recursive types anyway?

[DannyAziz]

@JClackett Did you ever figure this out?

[JClackett]

@DannyAziz. Nope! resorted to putting @ts-ignore's everywhere, which sucks really bad. Sometimes I hate tech. TS 4.6 coming out soon, saw that there were some updates to the recursive stuff so hopefully that fixes it.

I've got a few projects using this package and it does seem the larger the schema and the amount of relations you have per model affects the chance of this issue occurring.

[DannyAziz]

@JClackett I just tried out 4.6.0-beta and it still seems to happen

@MichalLytek Have you experienced this at all?

[amosbastian]

I'm also experiencing this and unfortunately have also ended up putting args as any everywhere it happens. I'm not sure when it started happening for me though and it seems to depend on the complexity of the Prisma models (if they have multiple relationships or not).

[SheaBelsky]

Anecdotally, one thing that resolved this issue for me was pinning the TypeScript binary used by VS Code to be whatever was installed locally.

Make a file at .vscode/settings.json with these contents, then restart VS Code. This resolved the error for me.

{
  "typescript.tsdk": "node_modules//typescript//lib"
}

Versions:

"@prisma/client": "3.8.1",
"prisma": "3.8.1",
"type-graphql": "^1.1.1",
"typegraphql-prisma": "0.18.4",
"typescript": "4.4.4"

[JClackett]

Yeah I have this setting enabled on all projects by default and still have the issue unfortunately :(

[zuhair-naqvi]

Any updates?

[JClackett]

Seems like this is a typescript issue in combination with a 'larger' prisma schema. Not sure this will be solved soon :(

[zuhair-naqvi]

Upgraded to Typescript 4.6.2, and I no longer face this issue. Seems like it's been fixed with https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#improved-depth-checks

[JClackett]

For me, it's stopped vscode from showing errors, but running a type check from the cli still errors. Which is strange because I've set vscode to use the workspace's typescript version and I assume the cli is using the same?

[zuhair-naqvi]

For me, it's stopped vscode from showing errors, but running a type check from the cli still errors. Which is strange because I've set vscode to use the workspace's typescript version and I assume the cli is using the same?

With 4.6.2 typechecks pass on CI as well, nextjs build commadn which is run on CI checks for validity of types and that passes so, maybe your CLI version's different?

[JClackett]

Anyone managed to find a solution for this? this is such an incredibly bad DX, as I lose all type safety.

[iquabius]

I'm stuck at version 4.1.6 to avoid this error.

Relevant dependencies:

{
  "dependencies": {
    "@prisma/client": "^3.14.0"
  },
  "devDependencies": {
    "nx": "14.5.2",
    "prisma": "^3.14.0",
    "prisma-nestjs-graphql": "^15.2.1",
    "ts-jest": "27.1.4",
    "ts-node": "10.8.2",
    "ts-node-dev": "^1.1.1",
    "typescript": "4.1.6"
  }
}

[ionut-badea]

Latest I tried and works it's 4.3.5

[JClackett]

Unfortunately I don't think this will be fixed anytime soon, if you have a significantly sized schema with a lot of relations, the amount of recursion in the types basically destroys typescript. I've tried every version of typescript, but I think my schema is just too big at this point, having to use "as any" everywhere to stop it blowing up... good times

[onadeemdev]

@JClackett any luck or updates?

[JClackett]

Unfortunately not :( leading me to start looking else where for other solutions

[MichalLytek]

I wish I could help, but if the issue is even with the TS types itself, I think it has to be reported in TypeScript Github repo issues, so that maybe they can help to fix it on compiler side or maybe model the types in a tail recursive way that won't blow the stack up 😅