Graphql-code-generator: [TypeScript] Allow to provide custom naming

[dotansimha]

Currently, there is only one namingConvention config, and the goal is to keep the current behavior, but also allow developers to separate it.

So this will still work:

namingConvention: module#method

But also allow to provide a default naming, with overrides:

namingConvention:
   default: module#method1
   enumValues: module#method2 
   typeNames: module#method3 

[benafa]

Is there any way of retaining enum names (rather than having them changed to CamelCase) in the current version?

[dotansimha]

@benafa
There is no option for that currently, until we'll implement and resolve this issue.

You can use the workaround suggested by @speakerwiggin in: https://github.com/dotansimha/graphql-code-generator/pull/969#issuecomment-443944864, and use 0.15.0-alpha.3c84ac73 version for now.

[SoyYoRafa]

Hi,
Will this support a "pass-through" mode? Our team would like strong coupling between our schema casing and TypeScript casing. We do not want anything transforming casing. If not, could you please add it? I can also send a PR on feature/custom-naming-convention.

[patrickr]

@SoyYoRafa my team shares your views and we have already had to work around this change. While I can't speak for what path @dotansimha will take as far as a "pass-through" mode to simply disable the naming-convention behavior, the current version already supports namingConvention: module#method so you can override this behavior with whatever function you want, which means you can provide a "pass-through" this way either with your own module or one you add to your project.

In our case we happened to be using the ramdajs library which provides identity a convenient little function that does nothing but return the parameter supplied to it. So our usage looks like ramda#identity

Your mileage may very :)

@dotansimha perhaps namingConvention should accept either a custom function, or boolean, where boolean would toggle the default behavior on and off.

[OneCyrus]

any update on this? the auto renaming broke us. We would prefer a pass-through option as well.

[dotansimha]

We are working on it: https://github.com/dotansimha/graphql-code-generator/pull/1092 https://github.com/dotansimha/graphql-code-generator/pull/1136

[dotansimha]

Hi @OneCyrus @patrickr @SoyYoRafa @benafa
We just merged https://github.com/dotansimha/graphql-code-generator/pull/1092 with support for changing the naming convention.

You can now specify the following config:

    config:
      namingConvention:
        default: change-case#pascalCase
        enumValues: change-case#upperCase

[dotansimha]

Fixed in 0.16.0

[OneCyrus]

thanks! the enums are now correctly upper case but we have a new issue with inconsistent naming of the enum itself see #1193

[SoyYoRafa]

How do we configure disabling change-case? Is there a no-change-case?

[gaberudy]

I discovered looking at the code there is a way to do a no-change-case, you specify keep as the option for the namingConvention. Here is my config for example:

generates:
  ./src/types/types.ts:
    plugins:
      - typescript-common
      - typescript-server
    config:
      avoidOptionals: true
      namingConvention:
        enumValues: keep

[robbyemmert]

This needs documentation. change-case is the only way mentioned in the docs.

[robbyemmert]

I love where the library is going, but I thought I'd share a couple of thoughts on backwards compatibility and breaking changes that could help avoid this type of situation in the future.

A summary of the problems people in this thread are facing:

• This change is inadvertently forcing opinionated conventions on adopters. This could force on-the-fly code changes when updating. This could be a barrier to entry, and is a stumbling block for anyone with a large existing project (there are certainly none of those around 😆).

• The opinions inadvertently introduced are actually outside the scope of this project. There are plenty of tools for managing coding conventions. To be honest, it can be a pain to have to manage that in multiple locations, and you certainly don't want to duplicate tslint...

• The breaking changes weren't properly documented. Not only is the default option a breaking change, but the way to turn it off isn't even documented. This makes updating like walking over a minefield for large projects.

Some simple solutions for avoiding these issues in the future:
Good Sense:

• Agree on a convention/philosophy for introducing breaking changes.
• Post that convention somewhere very public

My opinion (for what it's worth) on what that convention should include

• Defaults should maintain existing behavior by default (I realize this isn't always possible, but it's important when possible).
• Updates should be easy, and ideally limited to updating NPM and the library's configuration. Beware updates that require sweeping codebase refactors.
• Post a quick reference on how to turn new functionality off in the docs, where applicable.
• When features overlap with other common libraries (i.e. convention enforcement and TSLint), keep them disabled by default, or better yet, support them. You could, for example, allow for a hook for adding external linters or formatters instead of enforcing conventions yourself.

[dotansimha]

@robbyemmert I completely agree. One of the reasons it's hard to avoid these breaking changes it the way we previously wrote the codegen core and plugins. We recently did a complete refactor to the core and all plugins, and now it's easier to test and it almost fail-proof (because we are compiling every output in the unit tests with typescript compiler, and we know about most of the issues before users are getting them, thanks to ci).
We learned a lesson regarding breaking changes, and we are trying to avoid it. In the new refactor (which leads us to 1.0.0), we will introduce breaking change, but it's for the best, because we are now no longer use namespace and the output of the plugin has been minimized and optimized.
From now on, we will release a major version for breaking change, even the minor ones.