Maintaining consistency in typenames across upgrades

[tvvignesh]

Hi guys. I just tried out the code generator today and it rocks. Just have one queston/concern.

Since the type names are automatically generated (eg. args of createAccounts creates MutationCreateAccountsArgs) and we are using the generated types in the code we write which is perfectly fine, how do we make sure that type names do not break between upgrades in the future of graphql code gen?

If you start generating Mutation_Create_Accounts_Args instead of MutationCreateAccountsArgs in some version upgrade, I may have to end up changing numerous places where the type is referred and may actually become difficult to do.

Though I understand there are bound to be some breaking changes, I just wanted to understand how to handle such changes if it happens in the future (Ofcourse I am checking in the types along with the source and so I can roll back anytime but wanted to know if there is any clear upgrade path during such instances).

Thanks and great work with this lib 🎉

[dotansimha]

Hi @tvvignesh !
We are trying to keep output compatible as possible, and a few months ago we switched to publish each package as separate version - this allow us to use semver to declare breaking changes in the output of plugins.

We are trying to avoid those, and if it's not possible, we aim to proxy the previous type (example).

But as you stated - a breaking change in plugins output will results in a major version release (with release notes, of-course)