Expose addUnknownForEnums in Gradle service configuration

[vrendina]

Use case

We have a somewhat unique use case where we are bundling a GraphQL client and server inside the same application. We have an Android frontend application that uses Apollo Kotlin with a custom NetworkTransport to communicate with a native library that exposes a GraphQL server through an FFI.

Since the client and server are bundled in the same application, there is never any risk of having an older client communicating with a server using a newer schema. Any incompatible schema changes would prevent the application from compiling.

Because of this configuration, it is unnecessary for us to generate an UNKNOWN__ entry for enums.

Describe the solution you'd like

There is a field on the CodegenOptions called addUnknownForEnums that appears to be hardcoded to "true".

I understand this is a potentially risky setting for most use cases, but wanted to ask if there would be any possibility to expose the setting through the Gradle DSL or if there is another way I'm missing to apply this option?

It looks like it might be possible to achieve the desired behavior through a custom Apollo compiler plugin, but I wanted to ask about the existing boolean first.

[martinbonnin]

Interesting use case! Fun fact, addUnknownForEnums was added when trying to generate server code from SDL (see bdf78aa). Since then, we went another route with "implementation first" instead of "SDL first" but that use case has some similarities with yours.

It'd be nice to support this indeed. I'm not sure we want more parameters in the Gradle service though. There are a lot of parameters already.

My current train of thought is that we should instead move most of the codegen configuration to a foreign schema (like kotlin-labs for an example). This would make it a lot easier to make a maven/amper plugin for an example.

Something like so:

extend type MyEnum @generate(as:  Enum | SealedClass, withUnknown: true)

Also ultimately, we might want to generate sealed interfaces by default. They have a bunch of advantages over enum classes (rawValue + known types).

tldr; it'd be nice to support this but there a fair amount of backstory there and evolving this safely might take a bit of time. If you can achieve this with compiler plugins, it'll probably be faster. I think registerKotlinOutputTransform() and filtering the KotlinPoet models is how I would try to do it but I've never attempted this. Let us know if that work if you try!