Prisma1: Prisma client - generate enum types

[maxprilutskiy]

Is your feature request related to a problem? Please describe.
Prisma client should take advantage of TypeScript's enums instead of just using type

Describe the solution you'd like
I would like to make codegen module generate TypeScript enums from GraphQL's enums, instead of types.

Advantages:

1. More obvious;
2. Utilizes TypeScript language features;
3. Improves compatibility with other libraries related to code generation.

[maxprilutskiy]

I am going to submit a PR with this change

[maxprilutskiy]

PR: #3438

[schickling]

Thanks a lot for opening this issue and suggesting this change. This is a little bit tricky since the enum TS syntax and the currently supported string literal syntax are not compatible (this is by design - see this Github issue).

Your proposed change would result in a breaking change which would in most cases require a more explicit syntax. Consider the following example based on the giving datamodel.prisma snippet:

Datamodel:

enum Color { Red, Blue }

Resulting TS client types using literal string syntax (current implementation):

type Color = 'Red' | 'Blue'

// allows for the following
const c1 = 'Red' // ok
const c2 = 'Green' // compile error

Resulting TS client types using enum syntax (your suggestion):

enum Color {
  Red: 'Red',
  Blue: 'Blue'
}

// allows for the following
const c1 = 'Red' // compile error
const c2 = 'Green' // compile error
const c3 = Color.Red // ok

---

There is however a workaround described in the comments of the mentioned issue which would allow both the 'Red' and the Color.Red syntax. See the following:

export type Color = 'Red' | 'Blue'
export const Color: {
  Red: 'Red',
  Blue: 'Blue',
} = {
  Red: 'Red',
  Blue: 'Blue',
}

// allows for the following
const c1 = 'Red' // ok
const c2 = 'Green' // compile error
const c3 = Color.Red // ok

While my suggested workaround wouldn't use the canonical enum syntax you've described, it would still allow for both referencing syntaxes. Does this solve your requirements?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[VRspace4]

Any progress on this? The difference in the way Prisma generates the enum (string unions) versus my GraphQL client's way (typescript enum) causes conflicts in the types.

[chrisui]

I would like to throw weight behind switching to canonical enum syntax here. I personally only see the explicitness as a positive especially since enum values should ideally be seen as opaque. This change would also help the generated types follow a favourite POLA! :)

[WaqasAliAbbasi]

Any progress on this? The difference in the way Prisma generates the enum (string unions) versus my GraphQL client's way (typescript enum) causes conflicts in the types.

I fixed the incompatibility between GraphQL Code Generator enums and prisma client enums by setting enumAsTypes:true in codegen.yml. See here for more details.