Dynamic `Breaking` value about graphql-schema_comparator HOT 4 CLOSED

breaking in certain cases

just curious, what's an example of that?

from graphql-schema_comparator.

For example:

Adding an input field is not really breaking when the field is nullable. But definitely breaking when that input field is non-null.

from graphql-schema_comparator.

Oh, I see, I guess I always thought of them as two separate cases, like:

• Adding an optional argument or input field is not a breaking change
• Adding a required argument or input field is a breaking change

I thought this issue might have been about application-related breaking changes. For example, we've been considering changes like: "field x returns interface y, it used to return object z (part of interface y), but we're going to switch it to return object q in some cases (also part of interface y)." So it's not breaking from GraphQL's perspective, but it could break client code, because the API response doesn't match their expectations. Another problem, I suppose!

from graphql-schema_comparator.

Good point! These ones are tricky also 🤔

from graphql-schema_comparator.