Should a variable value of undefined be converted to null?

[yaacovCR]

See ardatan/graphql-tools#1453

[yaacovCR]

Variables not present within the variableValues object are left alone (https://github.com/graphql/graphql-js/blob/master/src/execution/values.js#L103) but variables present but undefined are later coerced to null.

This may be by design?

[IvanGoncharov]

@yaacovCR Excellent question 👍
Technically it's correct according to the spec:

Let hasValue be true if variableValues provides a value for the name variableName.

http://spec.graphql.org/draft/#sel-JANLLFCFFJCAACIB1nF

But pragmatically in JS we can treat undefined as absent value.
However, we need a consistent approach to undefined in this library and since undefined returned from resolver is converted to null we need to maintain the same rule in all other places that work with values.
Does this fully answer your question?

[IvanGoncharov]

@yaacovCR Thinking more about this maybe we need to change this in the next major version.
Do you know how widespread it is to set allowUndefinedInResolve to false in user codebases?
https://github.com/ardatan/graphql-tools/blob/2b1b5e3e48f23a81b286c48134507b6666eb0ccc/packages/schema/src/makeExecutableSchema.ts#L51

[yaacovCR]

I'm not sure I understand the correspondence you're making between conversion of undefined to null within the return value of resolvers and the issue here...

I would think passing a value of undefined in the variable values should be equivalent to not passing it at all and returning undefined in a resolver should be equivalent to not returning anything which should also be coerced to null...

[yaacovCR]

but in regards to your question, I am not personally sure, others might know better, actually forgot that option existed

[yaacovCR]

To use typescript terms, maybe, I think undefined and void should be treated the same within graphql-js...