Graphql-code-generator: Make Enums keys a PascalCase by default

[RIP21]

If you take a look at typescript docs, you can see that Enums are PascalCase.
But here when you have enum generated, they are taken as is from the schema.
What do you think to generate left side as PascalCase while right side to be the actual value from the schema enum definition?

We have a huge codebase and many enums are already PascalCase having them mixed is rather a pain in the ass.

Schema:

enum SomeEnum {
  COOL
  NOT_COOL
}

Current:

enum SomeEnum {
  COOL = "COOL",
  NOT_COOL = "NOT_COOL"
}

Proposed:

enum SomeEnum {
  Cool = "COOL",
  NotCool = "NOT_COOL"
}

What do you think?
Maybe an option?

[dotansimha]

@ardatan can you please re-implement this with the latest plugins API?

[dotansimha]

Fixed in 0.14.2 🎉

[janhartmann]

Is there any way to prevent this, this broke our current setup. :)

In our current setup we have resolvers like

// Generated GraphQL Enum
export enum UnitCriticality {
  Low = "LOW",
  Medium = "MEDIUM",
  Critical = "CRITICAL"
}

In a resolver somewhere I want to map my API response parent.criticality that returns "LOW", and I used to map it to an enum like so:

criticality: parent => {
    return UnitCriticality[parent.criticality]; // now returns undefined
},

But after updating and the enums is no longer uppercased. I can of course make a helper method but wonder if I can change the behavior?

[janhartmann]

Nevermind! I can just

return parent.criticality as UnitCriticality;

[lostpebble]

Is there any way to prevent this @dotansimha ? This change has messed up my rather large code base now cause all Enums have changed...

EDIT: This is not the first time this has happened with this project (The last pascal-case things caused big headaches too). Please consider making changes backwards-compatible, as in at least always provide an option to keep previous behaviour. If you have done so for this change, I appreciate it- but as of now I can't find any documentation on how to keep the old behaviour.

[lostpebble]

https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines

Please take a look at that. You seem to be making rash decisions here based on what exactly? The fact that the TypeScript project itself adheres to a certain style guide?

Even the TypeScript project - in bold and capital letters I might add - says that these guidelines are not prescriptive on the community at large at all. And the obvious reason is that every code base is different.

What you've seemingly done now is forced projects to conform to a certain style without any way to opt-out.

Moves like this make me wonder if the people working on this project actually use it in their own code-bases because these kinds of off-the-hip changes have real world consequences in sometimes massive amounts of code. Sure, the project generates code, but that doesn't mean that _all_ our code is generated- of course we will write custom code that depends on that generated code.

@ardatan and other contributers, I would love if you guys could weigh in on this. As I've said it is not the first time this has happened and its a little frustrating.

[dotansimha]

@lostpebble Sorry about that.
I know it's frustrating sometimes. But it's an open-source project, and we are trying to make everyone happy, it's not always easy.
We know that we are not always right, and in some cases it might effect developers. I welcome you to be part of the community and join discussions here, it might prevent mistakes like that in the future, because sometimes we are just missing things.

I opened another issue that's in WIP now: https://github.com/dotansimha/graphql-code-generator/issues/977 , it should allow more flexibility in the output.

[lostpebble]

@dotansimha I appreciate that you're looking into it already. I missed that WIP, and I think its a good direction to go.

I'll try be more active in the community as well to help however I can. I understand that open source is a group effort and sometimes certain things go under the radar.

Right now, I think the main thing contributors should strive for wherever possible is backwards compatibility. And just to make the options required for old functionality visible in version release notes and documentation. IMO, in a project like this it is even more important than most, as even small changes in generated output can have huge (and sometimes difficult to find) consequences in potentially huge code bases.

[robbyemmert]

Is there any way to prevent this @dotansimha ? This change has messed up my rather large code base now cause all Enums have changed...

EDIT: This is not the first time this has happened with this project (The last pascal-case things caused big headaches too). Please consider making changes backwards-compatible, as in at least always provide an option to keep previous behaviour. If you have done so for this change, I appreciate it- but as of now I can't find any documentation on how to keep the old behaviour.

This is costing me money right now. Please document breaking changes (or avoid them if possible).

[NickTomlin]

I recently encountered this when I needed to map enums in my schema to enums owned by another service. To preserve the enum values as-is (e.g. MY_ENUM_VALUE -> MY_ENUM_VALUE) you can use the namingConventions config in codegen:

config:
  namingConvention:
    enumValues: keep

If that still doesn't do what you'd like, you should be able to provide a custom mapper