jarwol / graphql-schema-utils Goto Github PK

I've just seen an issue where a backwards incompatible change has been detected, when a field went from optional to required in the API output.

I'm not sure that this should be backwards incompatible?

Field type changed on field User.cart from : `"Cart"` to `"Cart!"`.

On the wire, this will be either null or an object. Clients using checks or even codegen may be currently supporting this as optional (i.e. with a Maybe(Cart) type), but given that the format on the wire looks identical in the required case, I think it's fully backwards compatible.

Would be keen to understand if this is not backwards compatible in the general case, or get a fix out if it is.

Field type changed on field MarkAllIdeasAsSeenInput.ideaIds from : "[ID!]!" to "[ID!]".

I just got this output from some tooling that we use built around graphql-schema-utils. To my understanding, an input field changing from required to not-required is a backwards compatible change, so this looks like a bug.

Could you confirm whether this is expected or not, am I missing details about backwards compatibility here?

Given that GraphQL's type/interface matching syntax provides powerful control over the format of returned data, I believe adding types to a GraphQL Union should be considered backwards compatible.

I could see the option for adding a strict mode where this case, and potentially also the addition of new values to enums, are considered backwards incompatible, but with the affordances given by GraphQL'- structure, semantics, and syntax, I believe the default behaviour here should be to be backwards compatible.

when merging, I got the problem. it seems other.getFields() has no Object.prototype. It works with replacing it with Object.prototype.hasOwnProperty.call(other.getFields(), key)