Open martinbonnin opened 1 year ago
pulls kotlinx-datetime in the dependencies
Because of this it would probably be preferable to keep it as an opt-in IMHO. So opt-in could be 2 steps: 1. set some flag to true 2. add the dependency(ies)
Because of this it would probably be preferable to keep it as an opt-in IMHO
Just to be clear, the proposal is to pull kotlinx-datetime
only if the schema contains DateTime
scalars. All other users would be non-affected
Just to be clear, the proposal is to pull kotlinx-datetime only if the schema contains DateTime scalars. All other users would be non-affected
Although that would require parsing the schema at Gradle configuration time which doesn't sound great. But maybe acceptable 🤷
To check: is one of the current adapters we have over here already compatible with https://scalars.graphql.org/andimarek/date-time?
Use case
The
DateTime
scalar is specified at https://scalars.graphql.org/andimarek/date-timeIf the codegen schema contains such a scalar:
We could detect it at build time automatically and map it to
kotlinx.datetime.DateTime
Pros:
kotlinx.datetime.DateTime
is better to use compared toAny
(current solution)Cons:
kotlinx.datetime.DateTime
but maybejava.time.DateTime
or some other custom classkotlinx-datetime
in the dependenciesQuestions: