codegen not generating custom scalar types.

[anzecesar]

Hi,

I might be missing something, but I have the following issue.

I'm fetching the schema from a remote server and trying to generate case classes for a query.

in my build.sbt I have:

graphqlSchemas += GraphQLSchema(
  "staging",
  "staging schema at https://api.acme.com/graphql",
  Def.task(
    GraphQLSchemaLoader
      .fromIntrospection("https://api.acme.com/graphql", streams.value.log)
      .loadSchema()
  ).taskValue
)

graphqlCodegenSchema := graphqlRenderSchema.toTask("staging").value

This schema has some scalars defined

e.g.

# This represents a json encoded into a String.
scalar JsonString

which is then used in types

type MyAwesomeType implements Node {
   [...]
   meta: JsonString!
   [...]
}

code generation works, but compilation fails.

In the generated code, it appears as:

case class MyAwesomeInput(something: String, ..., meta: JsonString)

which will fail at compilation step, because JsonString isn't defined:

[error] /.../acme/target/scala-2.12/src_managed/sbt-graphql/AcmeMutation.scala:27:135: not found: type JsonString
[error]   case class MyAwesomeType(something: String, ..., meta: JsonString)

Interestingly, ID is defined as type ID = String. I guess it's a built in GraphQL type, since I don't see it defined in the schema anywhere explicitly.

I suspect the same might apply to enums defined in the schema.

[muuki88]

Thanks for your detailed bug report 👍

We don't have any test for scalar type definitions like you posted. It could very well be that this feature is missing.

Do you have the time and interest to do a pull request 😎? I'll be more than happy to help you 🤗

[jonas]

Yes, scalar types are currently ignored.

• https://github.com/muuki88/sbt-graphql/blob/master/src/main/scala/rocks/muki/graphql/codegen/TypedDocumentParser.scala#L54

I don't remember how sangria represents it should be a matter of generating a type alias similar to how it is done for the built-in ID scalar type.

• https://github.com/muuki88/sbt-graphql/blob/master/src/main/scala/rocks/muki/graphql/codegen/TypedDocumentParser.scala#L196

[muuki88]

@jonas is right. The type alias makes sense if it's actually only an alias. On the other hand there a some use cases for custom scalars, e.g. DateTime. Sangria's section on custom scalar types describes how to implement them.

For custom scalar types we would need additional imports ( #29 ) as we cannot generate code for something we don't know ;)

[anzecesar]

Yes, according to graphql docs:

Then it's up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the Date type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.

The sad part here is as you pointed out already, there is no way to infer this serialisation just from the schema alone. DateTime could be encoded as a String or as an Int or anything in between :). So much of strongly typed 😂

I think your solution in #29 makes most sense.

I could give implementing it a shot :).

I'm closing this in favour of #29.

[muuki88]

Thanks a lot @anzecesar 😊 looking forward to a pull request. If you need any help, just open the pull request with the code you already have and we are more than happy to help 😊