introduce TransformEnumValues

[yaacovCR]

See #1634

This PR implements TransformEnumValues that allows conversion of individual enum values.

This PR does not yet rigorously support addition/deletion of values, just conversion.

Additional test cases are possibly required.

[theguild-bot]

The latest changes of this PR are available as alpha in npm: 6.0.14-alpha-1f3b14a1.0

Quickly update your package.json by running:

npx match-version @graphql-tools 6.0.14-alpha-1f3b14a1.0

[danielrearden]

suggestion: Would it make sense to also add a test for changing the value of an GraphQLEnumValue?

If I'm grokking the code correctly, outside of renaming an existing value this transform would also let the user modify the "internal value" associated with an enum value without necessarily changing the name. It might be a good idea to add a test for that as well.

[yaacovCR]

You can actually do that already without this transform simply by adding the enum values to the resolver map within stitchSchemas just as within makeExecutableSchema. Although you can change the internal value via this transform also, it's not the easiest way to do it.

I believe we test the easier approach, but can't find it at the moment. :(

[yaacovCR]

But makes sense to add test that works in this manner anyway, good idea!

[yaacovCR]

To think about, and to discuss, for all potentially interested parties :)

TransformInputObjectFields allows you to pass a generic inputFieldNodeTransformer that works on top of or instead of the field renaming logic.

Might it make sense to do that here?

It would be nice also when adding enum values (whether simply by extend within additional typeDefs or via a transform), to provide a way to convert those values to a value that actually exists within the target schema. So far, we only automatically handle conversion, but not new enum values.

Parallel issue is when deleting enum values instead of renaming, how to add logic to supply a value for that enum value within the source schema if the target schema returns that value. Passing an additional (reverse) converter might also be beneficial.

These issues, however, seem to affect scalars as well. Is there a more general/better solution, like an additional transform for converting leaf values without modification of the underlying types?

[yaacovCR]

Note that the EnumValueMapper type should really have the old external value be the second argument to parallel GenericFieldMapper, but that would be a breaking change, so might make sense to change in the next major version.

graphql-tools/packages/utils/src/Interfaces.ts

Lines 508 to 513 in df52bf8

	export type GenericFieldMapper<F extends GraphQLFieldConfig<any, any> | GraphQLInputFieldConfig> = (
	fieldConfig: F,
	fieldName: string,
	typeName: string,
	schema: GraphQLSchema
	) => F | [string, F] | null | undefined;