I was about to ask why I am getting a query genera...
# apollo-kotlins
Stylianos Gakis
11/14/2023, 2:30 PMI was about to ask why I am getting a query generated with
Optional<Foo?>generateOptionalOperationVariables.set(false)m
mbonnin
11/14/2023, 2:31 PMNote you certainly want
generateInputBuildersmbonnin
11/14/2023, 2:31 PMI was contemplating deprecating
generateOptionalOperationVariablesmbonnin
11/14/2023, 2:32 PMTo answer the initial question,
codegenModelsmbonnin
11/14/2023, 2:33 PMMost 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 PMRight, 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 😊
generateInputBuildersStylianos Gakis
11/14/2023, 2:34 PMWould 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 PMIssues are always welcome 💚
mbonnin
11/14/2023, 2:34 PMWe love issues
mbonnin
11/14/2023, 2:40 PMit isis 4.x right?generateInputBuilders
mbonnin
11/14/2023, 2:41 PMWe 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
mbonnin
11/14/2023, 2:45 PMBack 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 PMthank you color 2
m
mbonnin
11/14/2023, 2:46 PMWe should use a yaml configuration file instead 🙈
😱 1
not kotlin but kotlin colored 1
s
Stylianos Gakis
11/14/2023, 2:46 PMNo, 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
Stylianos Gakis
11/14/2023, 2:46 PMWe 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😂
mbonnin
11/14/2023, 2:47 PMProbably not yaml but having some data format for compiler options would save a lot of boilerplate
mbonnin
11/14/2023, 2:48 PMMaybe
*.kd👀 1
s
Stylianos Gakis
11/14/2023, 2:49 PMWhat is
.kds
Stylianos Gakis
11/14/2023, 2:50 PMHahaha alright, I clearly have not kept up with all of the Amper discourse 😄
😄 1
m
mbonnin
11/14/2023, 2:52 PMLots of discussions these days 🙂
s
Stylianos Gakis
11/14/2023, 2:53 PMYeap, 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 AMFor 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
agrosner
11/15/2023, 1:05 AMBut also eliminated a lot of those downstream errors
s
Stylianos Gakis
11/15/2023, 8:19 AMYeah, 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")
}
}apolloMetadata12 Views