You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 8, 2021. It is now read-only.
While GraphQL SDL doesn't yet support an expressive enough syntax for scalar value definitions, there is some mapping needed for custom scalars (e.g. DateTime in GraphQL SDL should map to string in TypeScript). This mapping is depending on the application's implementation and therefore needs to be configured in the graphqlgen.yml.
Here is a proposal for the configuration format:
scalars:
DateTime: string
Additionally, we should extend the validation logic of graphqlgen (similar to how types <> models are validated) to always require a mapping for custom scalars.
The text was updated successfully, but these errors were encountered:
Given that this doesn't seem to have moved forward yet, as an interim measure I'm wondering how useful it would be to have options similar to apollo client:codegen's passthroughCustomScalars and customScalarsPrefix? In the case of TypeScript at least, it's then easy enough to declare a global type definition for the scalar type name (with the option of attaching the prefix to avoid clashes with other global names). This approach has worked successfully for me with the output of apollo client:codegen. Worth creating a PR for?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
While GraphQL SDL doesn't yet support an expressive enough syntax for scalar value definitions, there is some mapping needed for custom scalars (e.g.
DateTime
in GraphQL SDL should map tostring
in TypeScript). This mapping is depending on the application's implementation and therefore needs to be configured in thegraphqlgen.yml
.Here is a proposal for the configuration format:
Additionally, we should extend the validation logic of
graphqlgen
(similar to how types <> models are validated) to always require a mapping for custom scalars.The text was updated successfully, but these errors were encountered: