separate scalars for input types in typescript

[hayes]

Is your feature request related to a problem? Please describe.

Currently scalar field on input types use the same types as scalars on normal types. It would be really useful to be able to use a separate map of scalars for input types.

My specific use case is that several of our scalars have normalization built in, so that the types that can be handled by internals of our graphql implementation are looser than those that are received from graphql. More concretely, resolvers can return looser types than those that the resolver will receive in its input arguments.

Some examples of this in our server implementation are:

• for ID fields, internally everything is coerced to a string, so an input ID field will always be string, but a resolver for an ID field can return a string, number, or BigInt.
• our custom DateTime scalar will always be a Date scalar in an input, but could be either a iso-date string, or a Date object when returned from a resolver.

Describe the solution you'd like

This could probably be implemented with a new inputScalar map in the plugin options that mirrors the scalar map. When present, it would generate a InputScalar map that has the same behavior as the current scalars, and would be used for all scalars in input types. When not specified, only the current Scalars type would be generated and both normal types and input types would use the same scalars type. Describe alternatives you've considered

• always generating an InputScalars map
• just providing the looser types for scalras, and using type asserts or coercions on inputs in resolvers.
• Writing a custom plugin

Additional context

I am happy to provide a PR to implement this, I just wanted to make sure this would be a reasonable change that would be likely to be accepted before spending too much time on it.

[n1ru4l]

related: https://github.com/dotansimha/graphql-code-generator/issues/2588

[tslater]

@hayes, given the amount of time that has passed, I'm curious if/how you've solved this? We're asking ourselves the same questions right now.

[hayes]

For server side stuff we decided writing our schema using a code first approach was better, so I wrote https://giraphql.com/. For client side, I don't remember if this was solved.

[tslater]

@hayes Thanks for letting me know!

[cometkim]

Without adding a new key it can be expanded as string | { input, output }.

I'd like to make a PR for this. Is there any other discussion I should be aware of? @n1ru4l @dotansimha