Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Fritiof opened this issue Oct 25, 2022 · 5 comments · May be fixed by #13
Closed

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

Fritiof opened this issue Oct 25, 2022 · 5 comments · May be fixed by #13

Comments

@Fritiof
Copy link

Fritiof commented Oct 25, 2022

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:
prisma-typebox-1

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
Copy link

joshmossas commented Aug 31, 2023

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
Copy link
Owner

adeyahya commented Sep 1, 2023

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
Copy link

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

@smiley-uriux
Copy link

smiley-uriux commented Sep 19, 2023

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants