https://kotlinlang.org logo
Channels
Powered by
#apollo-kotlin
Title
# apollo-kotlin
s

Stylianos Gakis

11/14/2023, 2:30 PM
I was about to ask why I am getting a query generated with 
Optional<Foo?>
when I got 
generateOptionalOperationVariables.set(false)
already setup, but it turns out that sub-modules do not inherit this behavior from the root schema module. I kinda assumed this would propagate since when I was doing sub-modules at first and I set the codegen method I got the compilation error “Specifying ‘codegenModels’ has no effect as an upstream module already provided a codegenModels” so I assumed everything is propagated this way. I wonder, is this distinction on purpose here? Would it make more sense for sub-modules at least default to the schema module? Would that even be possible perhaps? Has anyone else been confused by this before? Or just me 😄
m

mbonnin

11/14/2023, 2:31 PM
Note you certainly want 
generateInputBuilders
instead. I personnaly find it less confusing
I was contemplating deprecating 
generateOptionalOperationVariables
To answer the initial question, 
codegenModels
is a bit unique because it's a hard requirement that all modules in the same service have the same value (or the generated Kotlin won't compile)
Most of the other parameters can be set individually per/module but we could probably make the use the schema module value by default
s

Stylianos Gakis

11/14/2023, 2:33 PM
Right, so it’s the flipped. Everything is opt-in except for codegenModels (for obvious reasons). That makes sense, I just made the wrong assumption there then 😊 
generateInputBuilders
is 4.x right? We haven’t migrated to that yet, hopefully soon though 🤞
Would you like to track this “but we could probably make the use the schema module value by default” with an issue? I can skip making an issue if you’d like to think about it a bit more of course.
m

mbonnin

11/14/2023, 2:34 PM
Issues are always welcome 💚
We love issues
generateInputBuilders
is 4.x right?
it is
We could maybe backport it. Not spending too much time in 3.x these days but once 4.x lands we could make one final 3.x release to prepare for 4.x
Back to the issue of defaulting to schema module values, the main paint point is that there are a lot of compiler options these days and they have to be duplicated in the Gradle config as well so it's a lot of values to serialize/carry around and the whole thing is a bit error prone.
s

Stylianos Gakis

11/14/2023, 2:45 PM
m

mbonnin

11/14/2023, 2:46 PM
We should use a yaml configuration file instead 🙈
😱 1
not kotlin but kotlin colored 1
s

Stylianos Gakis

11/14/2023, 2:46 PM
No, if an alternative exists I don’t see a reason to back-port it, if anything I agree with you, a 3 -> 4 is a great opportunity to get rid of such things that don’t need to be in there anymore
👍 1
We should use a yaml configuration file instead 🙈
You had to sneak that in there didn’t you 😂
m

mbonnin

11/14/2023, 2:47 PM
😂
Probably not yaml but having some data format for compiler options would save a lot of boilerplate
Maybe 
*.kd
kotlin data files once that becomes a reality 🤞
👀 1
s

Stylianos Gakis

11/14/2023, 2:49 PM
What is 
.kd
? 👀
m

mbonnin

11/14/2023, 2:49 PM
s

Stylianos Gakis

11/14/2023, 2:50 PM
Hahaha alright, I clearly have not kept up with all of the Amper discourse 😄
😄 1
m

mbonnin

11/14/2023, 2:52 PM
Lots of discussions these days 🙂
s

Stylianos Gakis

11/14/2023, 2:53 PM
Yeap, which makes total sense with all the back to back announcements JetBrains have made these past few weeks.
💯 1
a

agrosner

11/15/2023, 1:04 AM
For the propagation problem, I wrote a wrapper plugin at my company to provide specific configurations we standardized, and made the plugin configure Apollo with project properties by default so that we can set them for all consuming modules. We really reduced boilerplate since we also have multiple services and many separate graphql modules
👍 1
But also eliminated a lot of those downstream errors
s

Stylianos Gakis

11/15/2023, 8:19 AM
Yeah, 99% of the submodules basically add these 4 things to their build.gradle.kts
Copy code
alias(libs.plugins.apollo)
...
apolloMetadata(projects.apolloOctopusPublic)
implementation(projects.apolloOctopusPublic)
...
apollo {
  service("octopus") {
    packageName.set("octopus")
  }
}
This could definitely be a convention plugin however. The thing is that I am figuring all these things out as we are now introducing 
apolloMetadata
to sub-modules, before everything lived in the schema module, so all this is new-ish to me 😄 When we eventually migrate to 4.x, and see what that needs (with the dependsOn etc) I will make a convention plugin for it, for sure.
3 Views
Powered by