typegraphql-prisma: 0.17.0 relation _count type errors

Describe the Bug With the change in 0.17.0 regarding the _count field, all my fluent api relations types are now giving type errors

import { Team, User } from "@generated"

  @FieldResolver(() => Team, { nullable: true })
  async team(@Root() user: User): Promise<Team | null> {
    if (!user.teamId) return null
    return await prisma.user.findUnique({ where: { id: user.id }, }).team()
  }
Type 'import("<path>/node_modules/.prisma/client/index").Team | null' is not assignable to type 
'import("/<path>/node_modules/@generated/models/Team").Team | null'.
  Property '_count' is missing in type 
'import("/<path>/node_modules/.prisma/client/index").Team' but required in type 
'import("/<path>/node_modules/@generated/models/Team").Team'.ts(2322)

Team.d.ts(38, 5): '_count' is declared here.

In your release notes you mention that the _count property is now non-nullable, but isn’t this just for the case when you pass in the option to select the _count property i.e

include: { _count: { select: { posts: true } } },

Related prisma issue

Basically, there’s now a mis match between what prisma is providing and what typegraphql-prisma is saying will exist, typegraphql-prisma is now always expecting a _count property, but I’m pretty sure this isn’t true?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

Forgot about the third option 🤦 Nullable _count so it will gracefully fail on custom resolvers if someone just don’t care 😛

It should be the default option, as it worked like that before the “upgrade”.

looks like @MichalLytek fixed this (❤️) in 0.18.2 if you want to check it out @JClackett

No, we need to use the same class, otherwise it would end up with duplicated names and types being not interoperable.

So users will need to choose:

  • enable _count feature, use it in generated resolvers + apply the include: { _count manually in custom field resolvers
  • disable _count feature, no support for that in generated resolvers, you can always extend the base type and add support for _count manually