Override field types option for mergeSchemas

[FluorescentHallucinogen]

I'm working on a tool that shows a visual diff between two GraphQL schemas (e.g the previous and current versions of the same schema). Added fields are marked in green color, deleted in red and modified in yellow. It's built on top of graphql-voyager and uses @graphql-inspector/core under the hood.

In order to display the deleted fields in Voyager I merge both schemas using mergeSchemas from @graphql-tools/merge.

The problem is that if e.g. Post.content in schemaA (the previous version of the schema) has the String! (non-null) type, but Post.content in schemaB (the current version of the schema) has the String (nullable) type, the Post.content in the result of mergeSchemas of [schemaA, schemaB] (in that order) will have the String! type (from the previous schemaA), not the String type (from the current schemaB). See the image below.

Could you please add an option for mergeSchemas that changes the behavior of merging non-null and nullable fields to use (override) the nullability from the latest schema from the array?

[FluorescentHallucinogen]

Also, if the field changes the type from e.g. Int to String, I get the following error: Error: Unable to merge GraphQL type "Post": Field "test" already defined with a different type. Declared as "Int", but you tried to override with "String". How to force override?

[ardatan]

You can try new onFieldTypeConflict option on the canary version of this PR;
#2065

In your case, you can overwrite the existing FieldDefinitionNode with the next one however you want.

[FluorescentHallucinogen]

@ardatan

Is it incorrect, because type boolean is not assignable to type OnFieldTypeConflict?

you can overwrite the existing FieldDefinitionNode with the next one

But how? :-/ I've tried onFieldTypeConflict: (existingField, otherField) => { existingField = otherField; }, but it doesn't work.

Could you please provide an example of onFieldTypeConflict that overwrites the existingField by the the otherField?

It looks like it's a good idea to add this example into onFieldTypeConflict JSDoc.

[ardatan]

@FluorescentHallucinogen

onFieldTypeConflict: (existingField, otherField) => {
   existingField.type = otherField.type;
}

[FluorescentHallucinogen]

@ardatan
I get a Cannot assign to 'type' because it is a read-only property. ts(2540) error.

I've tried the following:

onFieldTypeConflict: (existingField, otherField) => {
  Object.keys(existingField).forEach((key) => {
    delete existingField[key];
  });
  Object.assign(existingField, otherField);
}

to mutate existingField by reference, and it works, but I'm curious, is there a more clean and elegant way to do this?

I'm worried about the DX. What about making onFieldTypeConflict immutable (onFieldTypeConflict should return result of conflict resolving)? E.g.: onFieldTypeConflict: (existingField, otherField) => { return otherField; } to overwrite the existing FieldDefinitionNode and onFieldTypeConflict: (existingField, otherField) => { return existingField; } to keep the original one?

[FluorescentHallucinogen]

I've also found that onFieldTypeConflict is not called while merging e.g. String! and String.

[FluorescentHallucinogen]

@ardatan Just found https://www.apollographql.com/docs/apollo-server/api/graphql-tools/#ontypeconflict. The third info argument looks very useful.

Just curios, why onTypeConflict was dropped in the new graphql-tools?

[ardatan]

Old mergeSchemas of graphql-tools v4/v5 is for schema stitching not schema merging so it's renamed to stitchSchemas in v6.
You can see; https://www.graphql-tools.com/docs/merge-schemas#difference-between-merging-and-stitching
So onTypeConflict is not dropped from mergeSchemas because new mergeSchemas comes from old graphql-toolkit. You can check migration notes to see the differences between v5 and v6.

You're right about DX so I changed the signature like you said. And now onFieldTypeConflict is called if there is a conflict about nullability.
onFieldTypeConflict: (existingField, otherField) => { return otherField; }

CI will release new canary version in a few minutes.

Let me know if it works.

[FluorescentHallucinogen]

Let me know if it works.

onFieldTypeConflict: (existingField, otherField) => otherField works, but onFieldTypeConflict is still not called if there is a conflict about nullability.

[FluorescentHallucinogen]

Just tested stitchSchemas from @graphql-tools/stitch and it surprisingly works exactly as I need even without onTypeConflict! :) It correctly overwrites e.g. String! to Int and String! to String.

[ardatan]

Tests have been added for your cases;
https://github.com/ardatan/graphql-tools/pull/2065/files#diff-91cd70a4ebe73358bd0b8c72c5b83b9e
It should work now. I am not sure overwriting String! with Int is a correct behavior because it breaks the previous schema.