MichalLytek / typegraphql-prisma

Prisma generator to emit TypeGraphQL types and CRUD resolvers from your Prisma schema
https://prisma.typegraphql.com
MIT License
891 stars 113 forks source link

Module "./resolvers/crud" has already exported a member #465

Open baumandm opened 2 months ago

baumandm commented 2 months ago

Describe the Bug

After upgrading to 0.28.0 to address #450, I'm getting generated files that fail the TypeScript build with errors like this:

prisma/generated/typegraphql/index.ts:16:1 - error TS2308: Module "./resolvers/crud" has already exported a member named 'CreateManyAndReturnItemTypeArgs'. Consider explicitly re-exporting to resolve the ambiguity.

16 export * from "./resolvers/outputs";

This happens because two different classes are generated with the same name, CreateManyAndReturnItemTypeArgs, one in the resolvers/crud folder and one in the resolvers/outputs folder.

Everything worked correctly with the same schema in previous versions of typegraphql-prisma, this is just related to the new CreateManyAndReturn classes.

To Reproduce Here is a codesandbox that reproduces it, run npm start

Here's a simple schema.prisma repro:

generator client {
  provider = "prisma-client-js"
}

generator typegraphql {
  provider = "typegraphql-prisma"
  output   = "../prisma/generated/typegraphql"

  useSimpleInputs = true
}

datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

model Item {
  id         Int @id @default(autoincrement())
  name       String

  typeId     Int?
  type       ItemType? @relation(fields: [typeId], references: [id])
}

model ItemType {
  id            Int    @id @default(autoincrement())
  name          String @unique

  items Item[]
}

I've found three different ways to change the schema so it will build successfully.

  1. Changing the ItemType relation to be required instead of optional. Not sure why this works.
  typeId     Int
  type       ItemType @relation(fields: [itemTypeId], references: [id])
  1. Renaming the relation field to match the model name, type -> itemType
  itemTypeId     Int?
  itemType       ItemType? @relation(fields: [itemTypeId], references: [id])
  1. Leaving the ItemType relation optional, but renaming the ItemType model to something else e.g. Type.
  typeId     Int?
  type       Type @relation(fields: [typeId], references: [id])
}

model Type {
  id            Int    @id @default(autoincrement())
  name          String @unique

  items Item[]
}

For (3), it will generate a CreateManyAndReturnItemTypeArgs class and a CreateManyAndReturnTypeArgs class, but they no longer conflict with each other.

After all this investigation, I think the key is (2) and (3). I suspect the issue is that the class name generation works by concatenating a model and the relation field name, but that can cause a conflict with another relation name. Not sure how to get around that without adding some kind of separator between the model name and relation in the generated class name.

If there isn't a clean fix for this, feel free to close it. I will likely go with (2) as a workaround.

Thanks!

Expected Behavior The generated files should build successfully.

Environment (please complete the following information):

leomylonas commented 1 month ago

I'm also facing this issue. I ended up using @baumandm's 2nd method to work around the problem, but I'd love a better solution to this.