typegraphql-prisma icon indicating copy to clipboard operation
typegraphql-prisma copied to clipboard

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

Open baumandm opened this issue 1 year ago • 1 comments

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):

  • OS: Codesandbox
  • Node: v20.12.1
  • typegraphql-prisma version: 0.28.0
  • Prisma version: 5.19.0
  • TypeScript version: 5.5.4

baumandm avatar Sep 03 '24 20:09 baumandm

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.

leomylonas avatar Oct 28 '24 22:10 leomylonas