Feature: Allow overriding built-in scalar types

[stubailo]

Specifically, sometimes we want to replace ID with something like this that can handle Mongo ObjectIDs: https://github.com/tmeasday/create-graphql-server/blob/79abbd67f4aef3b44fb8605e41eb2ba7978810a6/skel/resolvers/index.js#L8

I think it could be as simple as just allowing the schema to take a type called ID and just using that instead of the built-in.

[OlegIlyenko]

Had also similar requirements in quite a few places (but most importantly with IDs, which we represent internally as UUIDs). Though I implemented it with scalar aliases.

Just replacing a built-in scalar can be quite limiting since the schema can have different types of IDs

[leebyron]

This is pretty interesting. I think providing custom scalar types with the same name as the built-in types might break some core assumptions in the codebase that check for these built-ins. If taking that approach, look out for this. Allowing custom serialization behavior for these types could be pretty sweet. I would love to see a PR which added this in a nice way.

[alexmcmillan]

Is this likely why my example here fails, or should I open a new issue? This seems to work fine with 0.13.2.

[IvanGoncharov]

@alexmcmillan Thanks for the repo with reproduction 👍
But this is a totally unrelated issue since it was caused by #1382
Can you please open a separate issue?

[ghirlekar]

I have another use-case that would greatly benefit from this.

I want to override the serialization/deserialization of the String type to convert all Windows-style line endings to Unix-style for incoming/outgoing data. Some of my clients use Windows machines and some use Unix, and my database also has both style of line endings.

Overriding the String serialization/deserialization is a single point of change instead of all the different places I would need to add code to strip carriage returns.

Is there any plan to add this feature to an upcoming release?

[IvanGoncharov]

The problem here is that introspection depends on built-in scalars.
For example, if you override string to change line ending it will also affect string returned from introspection.
Even for scalars like ID that currently don't use by introspection can be used in future spec releases.
I think the correct solution would be to create custom scalars based on standard types (e.g. scalar UUID as String) which is proposed in graphql/graphql-spec#521 and attach validation/parsing/serialization to this scalar.

[CristianPi]

any workaround? casting and validation for ID?