Hello, is there a convenient way to customize code...

# apollo-kotlin

[goku]

Hello, is there a convenient way to customize codegen template (without manually going over the classes and modifying them)? Trying to add @JVMOverloads to data class constructors. Using v3.

[goku]

I found this but doesn’t work in following cases:
• if the Operation doesn’t have optional arguments
• for fragments
• for Inputs
I need this option to provide backward compatibility.

Ex: This change is binary incompatible. Precompiled code that calls UserFragment("John") will break when it is transitively upgraded to v2.

// v1
data class UserFragment(
  val name: String,
)

// v2
data class UserFragment(
  val name: String,
  val age: Int,
)

[bod]

Hi! Compiler hooks may help for this. They are experimental and not well documented but you can find a few examples here: https://github.com/apollographql/apollo-kotlin/blob/main/tests/compiler-hooks/build.gradle.kts#L91

(Note: to use them you need to use the id("com.apollographql.apollo3.external") plugin rather than the usual id("com.apollographql.apollo3") )

[mbonnin]

@goku are you shipping generated code as a public API? I wouldn't recommend this as there may be incompatible changes within the same major version of Apollo Kotlin.
We try really hard not to and I don't remember this ever being a problem but this may happen

[goku]

@mbonnin Public within the company. Not exposed to clients. Yes it is possible but Apollo Kotlin changes are not the concern. When we update Apollo Kotlin library we can run integration tests and compare binaries of the generated code.

The generated code is consumed by multiple teams at the company and every time binary of the generated code changes they are forced to have the latest of the generated code. A change made by one team effects everyone. I’m trying to make generated code more backward compatible so we don’t have to do library updates as frequently.

[mbonnin]

In your example, you would also need to pass a default age which apollo cannot really guess for you.

[mbonnin]

You could also take a look at multi module so that the team owning the consuming code also owns the query

[goku]

True, I’m looking at that case now. If the parameter doesn’t have default value it doesn’t make sense, or for fragments. You can ignore my comment on that. But input one is important I think.

We already do that. Whenever schema changes types in the schema module changes and that effects everyone.

I think Input is a good example. Adding a new nullable field to schema is a “safe” operation from the point of GQL Schema checks, but it is not safe on the client side since the binary of the generated code changes. addJvmOverloads should be added to Input imo.

[mbonnin]

Agree that addJvmOverloads should also impact input types. Want to open an issue/open a PR?

[mbonnin]

PS: if you're using v4, you can also use generateInputBuilders.set(true) to workaround this

[goku]

I discovered input builders yesterday but we are not in v4 yet. Once we migrate to v4 I will consider adding it.

Created the issue and added some notes:
https://github.com/apollographql/apollo-kotlin/issues/5397

I would like to create a PR as well but let me see if can find bandwith.