Naming conflict of exported member. Cannot use the word `Type` in schema.prisma

[Fritiof]

Hi!

First of all, thanks for creating this. It's a great tool! One issue though and likely it's with my naming of things, but I want to just see if there's something here that could be improved as I didn't foresee this issue when i created my prisma schema.

I have a schema.prisma which looks partly like this:

enum ComponentType {
  Select
  Text
}

model Component {
  id            String        @id @default(dbgenerated("uuid_generate_v4()")) @db.Uuid
  name          String
  type          ComponentType
  company       Company       @relation(fields: [companyId], references: [id])
  companyId     String        @db.Uuid
  componentData Json
}

The outputted index file from it looks like this:

.....
export * from './Component';
export * from './CompanyInput';
export * from './ComponentType';
....

This produces a problem in the outputted index.ts file like so:

Component.ts

import { Type, Static } from "@sinclair/typebox";
import { ComponentType } from "./ComponentType";

export const ComponentInput = Type.Object({
  id: Type.String(),
  name: Type.String(),
  type: ComponentType,
  company: Type.Object({
    id: Type.String(),
    name: Type.String(),
  }),
  companyId: Type.String(),
  componentData: Type.String(),
});

export type ComponentInputType = Static<typeof ComponentInput>;

Because the file Component gets a generated type called ComponentType. This of course is something that is what it is but perhaps a thing to note in the readme (unless i missed it and it's already there).

I can of course get around this with naming my enum something like ComponentEnum instead

[joshmossas]

If I may make a proposal. I don't think appending "Type" to the end of the exported typescript types is a good approach. In the Typebox documentation they do not do this. They simply do the following:

export const A = Type.Object({
  a: Type.String(),
  b: Type.String(),
});

export type A = Static<typeof A>;

That means the code that is generated differs from standard Typebox conventions. It also opens up the possibility of name conflicts as outlined by this issue. Because of this I personally think it's preferable to omit the "Type" suffix altogether.

Alternatively, if you want to keep appending a suffix to the generated types perhaps a configuration option could be added that would allow users to edit the default suffix?

So for example something like this

generator typebox {
  provider = "prisma-typebox-generator"
  typeSuffix = "Blah"
}

Could produce something like this

export const A = Type.Object({
  a: Type.String(),
  b: Type.String(),
});

export type ABlah = Static<typeof A>;

What are your thoughts @adeyahya? I'd be willing to open a PR for either of these implementations. I have a working fork now as I needed a quick fix (https://github.com/joshmossas/prisma-typebox-generator), however it also has a bunch of other changes as well that were specific to our use case so each of those will prolly need to be reviewed as well.

[adeyahya]

If I may make a proposal. I don't think appending "Type" to the end of the exported typescript types is a good approach. In the Typebox documentation they do not do this. They simply do the following:

export const A = Type.Object({
  a: Type.String(),
  b: Type.String(),
});

export type A = Static<typeof A>;

That means the code that is generated differs from standard Typebox conventions. It also opens up the possibility of name conflicts as outlined by this issue. Because of this I personally think it's preferable to omit the "Type" suffix altogether.

Alternatively, if you want to keep appending a suffix to the generated types perhaps a configuration option could be added that would allow users to edit the default suffix?

So for example something like this

generator typebox {
  provider = "prisma-typebox-generator"
  typeSuffix = "Blah"
}

Could produce something like this

export const A = Type.Object({
  a: Type.String(),
  b: Type.String(),
});

export type ABlah = Static<typeof A>;

What are your thoughts @adeyahya? I'd be willing to open a PR for either of these implementations. I have a working fork now as I needed a quick fix (joshmossas/prisma-typebox-generator), however it also has a bunch of other changes as well that were specific to our use case so each of those will prolly need to be reviewed as well.

Hi @joshmossas I agree with you about suffix, let's make the major release Omit the suffix by default but we still support it through config.

I've been looking at your fork and I found it really good, you even make the prettier configurable, if you willing to open PR I would really happy to review and help on the documentation.

[joshmossas]

Okay, sure! I'll prep a PR once I get home In a few hours

[smiley-uriux]

I support the suffix being configurable but ideally the suffix would apply to the schema and not the type export (or in addition to).

I always use export type Foo = Static<typeof FooSchema> in my schema files to avoid having to use the helper type all over the place, and at least for my use case, needing both the schema and type in the same file absolutely happens so having separate names makes for more convenient imports.

[adeyahya]

Since I can't dedicate time to maintain this repository, I've updated the readme to refer to prismabox instead. This is because it offers better support, maintained, and has a more suitable name.